- Yair Mark
Today I was working on a project where one of our DB entities extends an auditing class. Essentially what this class does is add a number of fields, createdBy, dateCreated, updatedBy and dateUpdated. The class entity you want to be audited extends this class and must have fields mapped to those 4 in its table.
This makes auditing creations and modifications to this table really easy as you do not have to explicitly specify the user that did the creating or modification or the dates this happened. One thing that tripped me up a bit is that whatever you explicitly set in these fields gets ignored and is replaced by the logged in user. Normally this is fine but in my case I wanted the entity to be updated when responding to a rest call where the logged in user in this case is the system user not the person making the rest call. After doing a bit of digging I came across the Spring Documentation detailing how this works. spring by default seems to be using the security context to pull the username of the logged in user. In my case implementing the AuditAware interface may be a bit hacky as the user details live in the caller of the request. For now I have resorted to not using this auditing class and setting these details myself.