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: "GW Brown, Information Systems and Computing" <>
  • To: Tom Zeller <>, Grouper Dev <>
  • Subject: Re: [grouper-dev] changelog implementation sketch
  • Date: Thu, 05 Jun 2008 07:08:16 +0100


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

Archive powered by MHonArc 2.6.16.

Top of Page