Clarity PPM: Project Team table last updated date appears inaccurate


Article ID: 109966


Updated On:




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.


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 

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 


Component: ODRSM


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 and