Grouper Users - Open Discussion List

[Peter DiCamillo <>]

Querying the audit log works well. I have it working for new attributes assigned directly to groups, and for legacy attributes assigned indirectly to groups. Thanks!

Peter

On 11/23/15 2:25 PM, Peter DiCamillo wrote:

Thanks, I hadn't thought of that, and it looks promising. I'll do some testing and get back to you.

Peter

On 11/23/15 10:19 AM, Shilen Patel wrote:

Have you considered querying the audit?  Something like this:

String groupUuid = GrouperDAOFactory.getFactory().getPITAttributeAssign().findBySourceIdMostRecent(attribute_assign_id_from_change_log, true).getOwnerPITGroup().getSourceId()

Thanks!

- Shilen

On 11/22/15, 10:08 PM, "Peter DiCamillo" <> wrote:

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: [] 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