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: Wed, 18 May 2005 16:51:11 +0100

I don't know if we will have time to get to this today - or how much of the 453.6 grams remaining it would take up, but I have some questions about the way that effective memberships appear to work in the API and how we should deal with them in the UI:

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.

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.

3) The GrouperAccess and GrouperNaming whoHas methods return an effective list of subjects with a given privilege. In the UI would it make sense to be able to choose immediate or effective lists of privilegees as with group membership. Here I would like to show how a privilege came about. In particular, the current UI 'suggests' that privileges granted to some one due to a group membership should be modified on an individual basis - which may not be appropriate e.g. can you revoke a privilege for an individual when it was granted to a group?

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.

Apologies for the late posting...


--On 16 May 2005 16:02 -0500 Tom Barton

Grouper design call, Wednesday, 18 May 2005, 1200EDT (1600Z), 60 minutes

+1-866-411-0013 (toll free US/Canada Only), or
+1-800-392-6130 (alternate toll free US/Canada Only)
+1-734-615-7474 (Non-US/CA, non-toll free, no dialout) for SIP
PIN: 0109331 (followed by "#")


1. administrivia
. Internet2 Intellectual Property Framework
. agenda bash
. approve minutes
. review old AIs

2. incorporation of subject API into grouper API & UI

3. alignment of API and UI v0.6 development roadmap. Cf.

4. v0.6 roadmap timeline

5. your 453.6 grams of flesh

6. recap new AIs


GW Brown, Information Systems and Computing

Archive powered by MHonArc 2.6.16.

Top of Page