Grouper Developers Forum

[Tom Barton <>]

Tom, good initial swipe.

Gary, I agree with all points.

In addition, attribute names should come from the grouper_fields table. 
In particular, there's no [effective|immediate|composite] variants of a 
list field - that's a UI presentation thing.

Regarding the DN, perhaps we should consider a format using a compound 
RDN. Eg,

dn: name=memphis:courses:physics001.2008,
 uuid=038e36f8-c04b-4679-af79-1bb39806ccba

I think it's important for the uuid to be there, but also a 
human-parseable name.

I'm hoping that it'll be enough for effective changes to memberships and 
attributes to all have the same change_number in the table, ie, that we 
don't need to somehow express in LDIF that "this is an effective change 
necessitated by the original change X".

Tom

GW Brown, Information Systems and Computing wrote:
> Tom,
>
> This is starting to take shape. A few things to consider:
>
> 1) UUIDs for Stems and groups should be used. Name might be optional
>
> 2) Calling Stem.setExtension and / or Stem.setDisplayExtension also 
> changes any descendant group extension / displayExtension, each of which 
> might be a separate or subordinate notification. The current table would 
> group changes by transaction but if we need to record multiple changes - 
> to support querying by object and object type - we should know the 
> 'parent' change.
>
> 3) In a similar vein to 2) each group that has its effective membership 
> changed should be recorded as a subordinate change.
>
> 4) When a group is deleted there may be effective membership changes 
> elsewhere. It also becomes impossible to work backwards to reconstitute 
> the group - unless the current state of the group immediately prior to 
> deletion is 'stored'. We could in principle work forwards from the 
> beginning of time,  or a snapshot taken at a known time.
>
> 5) If a group type is removed from a group we also lose the ability to 
> work backwards to reconstitute any custom lists for the type
>
> 6) A change in group membership can also lead to a change in privileges 
> for any number of stems / groups
>
> 7) The table should include who made the change
>
> 8) We should also audit/notify when a Member's subject id is changed
>
> I'm sure there will be more murky details. Accumulating effective 
> changes and privileges may well be challenging.
>
> Gary
>
> --On 04 June 2008 18:54 -0500 Tom Zeller 
> <>
>  wrote:
>
> > I've worked out more details regarding representing changes in LDIF,
> > please take a look and comment.
> >
> > https://wiki.internet2.edu:443/confluence/x/lVw
> >
> >
> > In summary, here's an example where
> > - group description set to 'new description'
> > - subjectA is added as a member and consequently as an effective member
> > of a custom list
> > - subjectB is granted the ADMIN privilege
> > - the custom type 'oldtype' is deleted
> >
> >
> > dn: stem:group extension
> > changetype: modify
> > replace: attrDescription
> > attrDescription: new description
> > -
> > add: listImmediateMembers
> > listImmediateMembers: subjectA
> > -
> > add: listEffectiveCustom
> > listEffectiveCustom: subjectA
> > -
> > add: privADMIN
> > privADMIN: subjectB
> > -
> > delete: type
> > type: oldtype
> > -
> >
> >
> >
> > Thanks,
> > Tom
>
>
>
> ----------------------
> GW Brown, Information Systems and Computing
begin:vcard
fn:Tom Barton
n:Barton;Tom
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
email;internet:
title:Sr. Director - Integration
tel;work:+1 773 834 1700
version:2.1
end:vcard