Grouper Users - Open Discussion List

[Peter DiCamillo <>]

While I think I combining events could be made to work,  I was hoping to 
avoid the extra complexity of having the changelog consumer do that. 
Would it be possible to add a hook that would be called after the 
creation of a deleteAttributeAssignValue event? In my case, the hook 
could determine the group and add its UUID to the event, taking into 
account how we use attributes and the changelog at Brown. That would 
avoid trying to include in the event anything that someone might need. 
It would be just small amount of code in the hook, instead of added 
complexity in the changelog consumer.

Peter

On 11/22/15 8:31 PM, Chris Hyzer wrote:
> Can you save the deleteAttributeAssignValue event in memory and look for the 
> deleteAttributeAssignAssign event and process the two together?  Or maybe you 
> could look up the deleteAttributeAssignAssign event in the 
> grouper_change_log_entry table when processing the event for the 
> deleteAttributeAssignValue event... I hesitate to add info about other tables 
> since the change log table generally holds data at a table level, and there 
> is separation between these two objects.  Someone else might need 
> AttributeDef information, or other data we would run out of space in the 
> change log table.  For instance if it is an attribute on an attribute 
> assignment, do we want the real owner or the attribute it is assigned to?  If 
> it is a group/member attribute, do we want both of those in there?
>
> Thanks
> Chris
>
> -----Original Message-----
> From: 
>
>  
> [mailto:]
>  On Behalf Of Peter DiCamillo
> Sent: Saturday, November 21, 2015 11:16 PM
> To: 
>
> Subject: [grouper-users] Unable to determine group from 
> deleteAttributeAssignValue event
>
> I recently wrote about updating our custom changelog consumer to handle
> events for changes to attribute values. While working on that I've run
> into another problem. When I get a deleteAttributeAssignValue event, I
> need to be able to determine the group the event is for. The event
> provides its  attributeAssign, which would normally allow determining
> the group. However, for a deletion, the attributeAssign no longer exists
> at the time the event is processed. In every case I've seen the
> attributeAssign is deleted after the value is deleted.
>
> A solution that occurred to me is if the deleteAttributeAssignValue
> event could include the uuid for the group (or generalized object) that
> the deletion applies to. I'd want that to work for legacy attributes
> that are assigned indirectly to a group, and for "new" attributes that
> have been assigned either directly or indirectly to a group. Is that
> possibility, or maybe there's already some other solution?
>
> Peter