Whenever we have an article in status Draft, its audit works as expected.

Whenever we publish this draft article, the newly generated article's audit does not function properly.

Below are the detailed technical information:

• When we post a draft article, the activity KMArchiveAsCovered calls the activity CreateCoveredObject (step 5) to create a new article support article published object

• Even if we have some properties set on the page ‘newCovered’ they will get emptied. That is because the activity calls activity CreateWorkPage which on step 10 does a ‘Page-New’ of the ‘newCovered’ page and thus empty all its values

• The audit activity TrackSecurityChanges is then triggered. Its 3rd step is supposed to make sure that all previous values are present. However based on the tracer, we have seen that it populates the values entered by the user in the UI under the property ‘pyPreviousValues’ that is under page ‘newCovered’. However, the field values themselves are not set on the page ‘newCovered’. Example: newCovered.ArticleTitle=”” and newCovered.pyPreviousValues.ArticleTitle=”testing”

• The 4th step of the above activity will call the activity ‘TrackSecurityChangesLogic’ which will compare the current values and the old values. Since newCovered.ArticleTitle=”” and newCovered.pyPreviousValues.ArticleTitle=”testing”, it will deduct that the value was deleted and hence populate the field ‘ChangeTrackModel.pyHistoryMemo’ =“ChangeTrack_Remove ArticleTitle testing’. This field value will then be used by step 5 to set the audit action to “delete”

From the above scenario explanation, we can conclude that there is an issue with the java step#3 of the activity baseclass.TrackSecurityChanges: it is populating the values entered by the user only in the pyPreviousValue property which is interpreted as an action ‘delete’ of the audit