Skip to Content.
Sympa Menu

grouper-dev - Re: [grouper-dev] changelog implementation sketch

Subject: Grouper Developers Forum

List archive

Re: [grouper-dev] changelog implementation sketch

Chronological Thread 
  • From: Tom Barton <>
  • To: Grouper Dev <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Thu, 05 Jun 2008 09:35:26 -0500

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,

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


GW Brown, Information Systems and Computing wrote:

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.


--On 04 June 2008 18:54 -0500 Tom Zeller

I've worked out more details regarding representing changes in LDIF,
please take a look and comment.

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


GW Brown, Information Systems and Computing

fn:Tom Barton
org:University of Chicago;Networking Services & Information Technology
adr;dom:1155 E. 60th St.;;Rm 309, 1155 Bldg;Chicago;IL;60637
title:Sr. Director - Integration
tel;work:+1 773 834 1700

Archive powered by MHonArc 2.6.16.

Top of Page