Project Team Table Last Updated Date Appears Inaccurate
Article ID: 109966
Updated On:
Products
Issue/Introduction
Why is the field 'Last Updated Date' on the PRTEAM table being updated to be the time that the Time Slicing job last processed the record?
This causes confusion to the users because they did not make any changes to the Project Team records on the date specified.
In reviewing the Administration > Data Administration > Audit Trail (CMN_AUDITS table), the information on when and who updated the records is confusing and discrepant.
Environment
Component: ODRSM
Cause
If a change to allocation is made on a Project Team tab, the 'Last Updated Date' appears inaccurate.
The completion date and time of the Time Slicing job replaces the prior Last Updated Date of the time the actual user that made the change.
1. When allocation is updated, the
PRTEAM.last_updated_date and
PRTEAM.last_updated_by
the timestamp is updated.
2. When the Time Slicing job sees the change, it processes it and sets
PRTEAM.last_updated_date to be the Time Slicing job completion time.
So, the PRTEAM.last_updated_date is updated again
3. Each time an update occurs, the CMN_AUDITS uses the PRTEAM.last_updated_date and
PRTEAM.last_updated_by
To Summarize:
If a resource is added to the team and shows as Insert on the audit trail and then an indirect change is made to a resource such as Availability, Hire Date, Termination Date then the audit trail shows changed by the original person who added the resource to the team. Not the person who made the indirect change. The audit trail updates when the time slicing job runs and does not reflect the person who ran the time slicing job.
If a direct change is made to the allocation, such as changing the TSV values or segments, Start/Finish dates on the specific resource's Staff Member properties, the person who made this change will reflect on the audit trail and the time slicing job does not need to run.
If then an indirect change is made, the time slicing job does run, however the person who made the last direct change and NOT the person who made the indirect change or the person who ran the time slicing job shows as changed by.
Resolution
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:
The CMN_AUDITS.last_updated_date
and CMN_AUDITS.last_updated_by
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 15.4.1.4 and 15.5.1.2
Feedback
