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:49:31 +0100



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




Archive powered by MHonArc 2.6.16.

Top of Page