@Audited and @AuditOverride does not work consistently for embeddables that extend a mapped superclass

Description

> So the basic rule is:
> - fields from a non-audited mapped superclass are never audited, unless an
> @AuditOverride is specified
> - if the mapped superclass is audited, then its fields are of course audited
> as well
>
> > In the following, A.b.intValue should be audited; A.b.strValue should not
> > be audited.
> >

>
> Looks good
>
> > In the following, both A.b.intValue and A.b.strValue should be audited:
> >

>
> Yes
>
> > In the following, both A.b.intValue and A.b.strValue should be audited.
> >

>
> Yes
>
> > What should be the outcome of the following? Should A.b.strValue still be
> > audited even though A.b is explicitly not audited?
> >

>
> @NotAudited has precedence - so not audited.

...

> Adam Warski

Environment

None

Activity

Show:
Gail Badner
June 3, 2014, 12:42 AM

Currently, what is listed in the description only works if the embeddable class has (persistent) declared values.

As a workaround, when an embeddable class with no declared data extends a mapped superclass, auditing can only be enabled for the mapped superclass data by annotating the embeddable class with @Audited. For example,

Unfortunately, this will affect all audited entities that contain an embedded instance of that class. Currently, @AuditOverride cannot be used on an embedded field to disable auditing the mapped superclass (HHH-9228). The only way to override auditing for a particular embedded field is to annotate the embedded field with @NotAudited.

In addition, @AuditOverride( ... isAudited=false) does not for embeddables that extend a mapped-superclass.

Steve Ebersole
October 27, 2015, 7:15 PM

This bug report does not indicate that the reported issue affects version 5.x. Versions prior to 5.x are no longer maintained. It would be a great help to the Hibernate team and community for someone to verify that the reported issue still affects version 5.x. If so, please add the 5.x version that you verified with to the list of affected-versions and attach the (preferably SSCCE) test case you used to do the verification to the report; from there the issues will be looked at during our triage meetings.

For details, see http://in.relation.to/2015/10/27/great-jira-cleanup-2015/

Steve Ebersole
October 28, 2015, 3:25 AM

As part of verifying that this issue affects 5.0, please just set the "Affects version". Leave the "verify-affects-5.0" label and leave the issue in "Awaiting Response" status; these are critical for us to be able to track these verifications and triage them. Thanks.

Steve Ebersole
December 6, 2018, 3:43 PM

Preparing Alpha1 release

Assignee

Chris Cranford

Reporter

Gail Badner

Fix versions

Labels

backPortable

None

Suitable for new contributors

None

Requires Release Note

Affirmative

Pull Request

None

backportDecision

None

Components

Affects versions

Priority

Major
Configure