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: "GW Brown, Information Systems and Computing" <>
  • To:
  • Subject: Re: [grouper-dev] Grouper design call, Wednesday, 18 May 2005, 1200EDT (1600Z), 60 minutes
  • Date: Thu, 26 May 2005 14:24:11 +0100

--On 24 May 2005 09:42 -0700 blair christensen

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

Archive powered by MHonArc 2.6.16.

Top of Page