As mentioned earlier, one of the critical points with this check is when combining Conditional Auditing with the ValidityAuditStrategy.

One of the problems I have with the current conditional auditing approach is that it requires a great deal of reconfiguration and setup on the users part to simply control whether or not an audit operation should occur. The whole point of HHH-12326 Closed is to introduce an easier way to do this check by following a similar premise that JPA has with entity listeners.

One question I have been contemplating is limiting the conditional auditing to only entity update operations; e.g. RevisionType.MOD. I'm sure those who are using the listener approach to conditional auditing may be preventing RevisionType.ADD and RevisionType.DEL and I'd like to understand from your perspective the reasons why those should be conditional.

As I continue to work through conditional auditing for 6.0, the more I find myself convinced that conditional auditing should be limited to only entity updates.

One driving factor (but not the only one) is for the case when identifiers are reused on an audited entity. Lets say in the 2017 an entity is inserted, modified, and later deleted and the conditional auditing prevented the storing of the ADD and DEL operations. Later in 2018 another user creates an entity with the same identifier but this time the conditional auditing allows the ADD operation. This leads to questionable audit history in my opinion. I think its important that the history indicate when the life-cycle of the prior entity identifier ended as well as when the life-cycle of the latter incarnation began.

For those of you in this issue using conditional auditing, whats your take on that restriction?