user permission problem

HI All,

I was playing around with creating more complex user
permissions for  
my site. I made some category, user group and workflow
permissions  
that were almost working perfectly for a Super Editor user
group. I  
was using one of my real users as a Super Editor test case,
logging in  
as her on a safari browser while making the changes as an
admin in a  
firefox browser.

Anyway at some point all her Workflows disappeared. I
assumed I had  
made some silly mistake so delete all the new user groups
and  
workflows I had created leaving only the "all'
categories.

I made a new simple Super User group and assigned a new user
to it.  
The new use is able to access all workflows and stories as
expect.  
However when I assigned  my 'real' user (the one I was dong
all the  
testing with) to have the exact same Super User user group,
no  
workflows appear. (Note - I have tried logging in as my user
on  
firefox too, and restarting my browsers - and I still get
the same  
result ).

This doesn't make any sense to me. I did try searching the
BUG  
repository in case others have run into this but nothing
came up. Has  
anyone else run into this?

I did look at the database to see how group ids were being
assigned to  
the new user and the old 'real' user. As far as I can tell
the old  
user has had some member__id s set to false, which is good -
but I  
don't know if one group has been left as true when it should
be false.  
Maybe there is some SQL I could use to delete all the old
group  
associations for this user?

Any insight very welcome.

thank you
Dawn

On Mar 15, 2008, at 17:40, Dawn Buie wrote:

> HI All,
>
> I made a new simple Super User group and assigned a new
user to it.  
> The new use is able to access all workflows and stories
as expect.  
> However when I assigned  my 'real' user (the one I was
dong all the  
> testing with) to have the exact same Super User user
group, no  
> workflows appear. (Note - I have tried logging in as my
user on  
> firefox too, and restarting my browsers - and I still
get the same  
> result ).

Could the user be a member of some other group that DENYs
access to  
workflows?

> I did look at the database to see how group ids were
being assigned  
> to the new user and the old 'real' user. As far as I
can tell the  
> old user has had some member__id s set to false, which
is good - but  
> I don't know if one group has been left as true when it
should be  
> false. Maybe there is some SQL I could use to delete
all the old  
> group associations for this user?

Oy. I've don't recall ever seeing a permission issue that
was resolved  
by modifying the database directly. But if your new user and
real user  
are in exactly the same user groups but things look
different, then it  
certainly would suggest a difference between them. And if
it's because  
the real user is still a member of the broken group you were
testing  
(though disabled), that *might* be it. Hrm...it sure looks
like the  
various queries properly exclude inactive group memberships.
You'd  
probably have to put some debugging in  
Bric::Biz::Person::User::what_can to see what group IDs get
processed  
and what their values are.

HTH,

David

On 15-Mar-08, at 9:56 PM, David E. Wheeler wrote:

> On Mar 15, 2008, at 17:40, Dawn Buie wrote:
>
>> HI All,
>>
>> I made a new simple Super User group and assigned a
new user to it.  
>> The new use is able to access all workflows and
stories as expect.  
>> However when I assigned  my 'real' user (the one I
was dong all the  
>> testing with) to have the exact same Super User
user group, no  
>> workflows appear. (Note - I have tried logging in
as my user on  
>> firefox too, and restarting my browsers - and I
still get the same  
>> result ).
>
> Could the user be a member of some other group that
DENYs access to  
> workflows?

No - I deleted all the extra groups and was just left with
the default  
ALL groups. And I looked for DENY's and there were none.
>
>
>> I did look at the database to see how group ids
were being assigned  
>> to the new user and the old 'real' user. As far as
I can tell the  
>> old user has had some member__id s set to false,
which is good -  
>> but I don't know if one group has been left as true
when it should  
>> be false. Maybe there is some SQL I could use to
delete all the old  
>> group associations for this user?
>
> Oy. I've don't recall ever seeing a permission issue
that was  
> resolved by modifying the database directly. But if
your new user  
> and real user are in exactly the same user groups but
things look  
> different, then it certainly would suggest a difference
between  
> them. And if it's because the real user is still a
member of the  
> broken group you were testing (though disabled), that
*might* be it.  
> Hrm...it sure looks like the various queries properly
exclude  
> inactive group memberships. You'd probably have to put
some  
> debugging in Bric::Biz::Person::User::what_can to see
what group IDs  
> get processed and what their values are.

That sounds tiring.

I may just tell the real person represented by this
now-screwed up  
User account that I'm sorry but she'll just have to be
someone new but  
with fabulous new powers.

I suspect this could be a bug but I hope I never repeat it.

thanks
Dawn

>
>
> HTH,
>
> David
>

On Mar 15, 2008, at 20:12, Dawn Buie wrote:

> That sounds tiring.
>
> I may just tell the real person represented by this
now-screwed up  
> User account that I'm sorry but she'll just have to be
someone new  
> but with fabulous new powers.
>
> I suspect this could be a bug but I hope I never repeat
it.

LOL. I love your pragmatic approach. 

David