Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] Grouper design call, Wednesday, 18 May 2005, 1200EDT (1600Z), 60 minutes

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] Grouper design call, Wednesday, 18 May 2005, 1200EDT (1600Z), 60 minutes


Chronological Thread 
  • From: blair christensen <>
  • To:
  • Subject: Re: [grouper-dev] Grouper design call, Wednesday, 18 May 2005, 1200EDT (1600Z), 60 minutes
  • Date: Tue, 24 May 2005 09:42:48 -0700

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?
Acutally, this returns _GrouperList_ objects. Are you wanting a method
that only returns groups?

> 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.

> 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.

> 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.




Archive powered by MHonArc 2.6.16.

Top of Page