Grouper Developers Forum

["GW Brown, Information Systems and Computing" <>]

--On 24 May 2005 09:42 -0700 blair christensen 
<>
 wrote:

> On 2005.05.18 16:51, GW Brown, Information Systems and Computing wrote:
> > 1) The MemberVia class and grouper_membervia table keep track of the
> > chain  of group memberships that 'caused' an effective membership.
> > Currently there  is no public way in the API of obtaining this
> > information. Would it be  possible to have a GrouperList.chain method
> > which returned the list of  groups by which an effective membership came
> > into being? This info would  probably be shown on a separate web page.
>
> Does the current _GrouperList.chain()_ method not already do this?
It does - I wasn't looking for it here.

> Acutally, this returns _GrouperList_ objects.  Are you wanting a method
> that only returns groups?
I'm happy to work with GroupeLists
> > 2)Similarly, a GrouperList.firstInChain method would allow me to
> > indicate  in the UI which immediate membership of the current group
> > caused an  effective membership.
>
> _GrouperList.via()_ provides the first group in the via chain.
Confusion over direction! I was working from the 'working' group to the 
immediate membership ultimately responsible for the effective membership 
i.e. if groupA has groupB as a member has groupC as a member has subject Z 
as a member I was interested in groupB->groupC
> > e.g. can you revoke a privilege for an individual when it was granted to
> > a group?
>
> You should not be able to.  If you can it is a bug.  You need to remove
> the individual from the group that they are an immediate member of to
> revoke the privilege.
I wasn't suggesting that this happened - just that anyone using the UI 
would in effect try to do this. I think we need to make it clear, in the 
UI, how a subject came to have a privilege/membership - atleast as a 
prerequisite to modifying privileges/memberships. It is impossible to know 
what to expect otherwise.
> > 4) In principle a subject may be a member of a group by > 1 effective
> > membership, or may have the same privilege due to effective list
> > memberships. In practice, however, I think that the API doesn't always
> > allow this. In general it checks to see if an effective membership
> > already  exists before adding a new one - however it checks if any
> > effective  membership exists and not the particular one being added. If
> > this is  changed to allow multiple effective memberships then we also
> > need to be  specific about what we remove - so the UI needs to tell the
> > API which one  to remove.
>
> Do you have an example of this?  The membership code remains messier
> and less tested than I would like so it is quite conceivable that a bug
> like this exists.  If so I'd like to fix it.
I tried to reproduce this  - but couldn't. I think I may have run into some 
database inconsistencies for groups created prior to some bug fixes.
>



----------------------
GW Brown, Information Systems and Computing