This is reported as DE44708 to review the behavior of the Audit Trail (CMN_AUDITS).
1. Prior to Clarity 15.3, this is how Audit Trail worked:
do not reflect that of the TIme Slicing job
Consider the following scenario:
Let's say there are records in the CMN_AUDITS table showing allocation change records.
If the Purge Audit Trail job runs and removes records from the CMN_AUDITS trail, there is no more history of the change.
Now if an indirect change was made in the UI, e.g. the hire / termination date was changed for a resource team member, this will affect all records on the team allocation (PRTEAM).
The original date of PRTEAM.Last_updated_date will show in the Audit Trail again, indicating that someone made a change to allocation.
The actual user making the change will show.
2. Because of the scenario above, customers did not want this behavior, so a change was made in 15.3 as customers wanted to track indirect changes, and the way to do that was via the user who ran the Time Slicing job. Only the last_updated_date was updated, but not the actual person making the change.
The current framework does not support both scenarios so the best approach as a collective decision to revert back to how it was working prior to 15.3.
So if we audit the resource hire/term date and use it in parallel with old records that were purged, this would signal an indirect update.
3. Therefore, the change in Clarity15.6 is a revert to how it was working prior to 15.3.
When allocation is changed by the user, the PRTEAM.last_updated_date now uses the date stamp the moment the change was made and not that of the Time Slicing job completion time.
This propagates to the CMN_AUDITS table.
This issue is fixed in Clarity PPM 15.6 release. It is also included in the patch 220.127.116.11 and 18.104.22.168