Grouper Developers Forum

["Tom Zeller" <>]

On Thu, Jun 5, 2008 at 1:08 AM, GW Brown, wrote:

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.

OK, I've updated the examples with a parent change identifier column.

 

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.

For some changes, we might include a snapshot representation of the group immediately prior to the change, either in the change representation itself (which seems non-standard for LDIF and difficult for pluggable representation implementations) or a 'previous_representation' column or a separate (linked) table. I don't think we would want to do this for every change, for performance reasons.

 

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

 I'm not clear on the above, makes sense though...could you provide more details please ?

 

7) The table should include who made the change

Right, the examples now contain subject_id and '...' meaning other columns, such as Chris' suggestions like act_as_subject_id, etc.

 

8) We should also audit/notify when a Member's subject id is changed

I've worked out an example for this.

Thanks for your comments!

Tom