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.
In the meantime I'll look at removing links from subjects when we are 
showing effective memberships.
> > 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.
I thought it produced the last in the chain - but I'll let blair clarify!
> > 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.
There is a bit of a conundrum. If privileges are externally managed then 
Grouper can do a fair job of assigning the privileges in the first 
instance, but listing / modifying those with privileges might be best 
achieved through an external UI. I'm sure that could be achieved, however, 
it still leaves the question of what we do in Grouper by default. We either 
have to:
1) enhance the access and naming APIs - in which case an external 
implementation could choose to fulfill those APIs, or
2) in Grouper we take advantage of the way list attributes work, and 
'force' anyone using an external privilege system to provide an external UI

I think we need to come up with something for 0.6, however, if we are not 
realistically expecting others to implement external privilege management 
just yet, we could go with 2 as a stop gap and consider the appropriate 
solution later.
> > 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.
I'll try and see if I can reproduce it in code snippet.
>



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