Grouper Developers Forum

["Tom Zeller" <>]

On Fri, Jun 6, 2008 at 3:27 AM, GW Brown <> wrote:

Also, the change_number is always 001 in the examples. I assume it is incremented with each change?

Yes, I've made that more obvious now.

 

The stem extension change example show the object_type for the stem as group...

oops.

 

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

I've worked out an example for this. 

Interesting. Strictly speaking we don't remove/add members where we change subject id, on the other hand consumers of the affected groups would probably want to 'know' about such changes. Possibly we could indicate the member_uuid as well as the subject identifiers without implying and add/remove?

 Ah, right, membership persists when subject ids change as far as grouper is concerned. Perhaps consumers would just have to know whether or not to ignore consequent membership changes in the same change as a subjectId modification.

This seems similar to a 'delete group' where additional information (representation of the object(s) prior to or after the change) would be useful.

Jokingly (you know, XML solves everything) I once typed up

<AuditRecord>

 <old>

  ...LDIF...

 </old>

 <new>

 ...LDIF...

 </new> 

 <change>

 ...LDIF...

 </change>

 <affectedObjects>

 dn:...

 dn:...

 </affectedObjects>

</AuditRecord>

but we might as well cook up our own XML representation of changes then.

Maybe grouper objects (groups, members, memberships, subjects, stems, fields) should each have their own LDIFy representation with an identifying objectclass which might make such representations easier, dunno, I will experiment more.

TomZ