Grouper Developers Forum

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

--On 23 May 2005 10:01 -0500 Tom Barton 
<>
 wrote:

> blair may need to add further details to my comments below. -Tom
>
> GW Brown, Information Systems and Computing wrote:
> > 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.
>
> Ought to be possible. I can imagine this developing into an interesting
> problem on how best to browse directed graphs. However, I'd like us to
> resist going in that direction until we've solved another interesting
> problem, and one we're on hook to do for v0.7-0.8: dealing with group
> math.
GrouperList.chain does, as blair pointed out, already exist. I've attached 
3 images which show how we could present the information

members.png->Effective member is no longer a link - but [test1] is and 
would link to the membership/privilege screen for [test1] with respect to 
[test2]

members1.png->As above, however, the mouse would be hovering over the 
'membership chain' link (could be an icon).

chain.png ->result of clicking on 'membership chain' link. I haven't made 
the groups links - so no navigation issues yet.

I understand that group math may be harder to represent but I don't think 
that ought to stop us showing the information in chain.png.


> > 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.
>
> I think GrouperList.via does that currently.
>
> > 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?
>
> Hmm, one might construe some divergence between an abstracted privilege
> model that is basically flat (you've either got the priv or you don't)
> and Grouper's implementation in which privs can follow effective
> membership. In an implementation that actually uses an external privilege
> management interface, it may well be that groups are used to effectively
> grant privilege. To manage Grouper privs in such an environment, an admin
> would need to use the priv management interface to manage Grouper privs,
> including dealing with groups. So perhaps what's needed is for the
> Grouper UI to have a priv management section of the group management
> workflow that's distinct from management of membership and other group
> attributes.
>
> > 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.
>
> It is and should be only possible to modify immediate memberships.
> Effective membership is only implicit. Multiple immediate memberships may
> imply the same effective membership. An effective membership is removed
> upon removal of the last qualifying immediate membership. If you see
> things working otherwise, I bet it's some type of bug.



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

Attachment: chain.png
Description: PNG image

Attachment: members.png
Description: PNG image

Attachment: members1.png
Description: PNG image