How do I revert a record back to its OOB configuration

[brian-rowland]

Prior to Aspen, there was the BaseLine update set which captured the out-of-box values for an update synched record the first time it was modified. This allowed me to review any entry in sys_update_xml against its out-of-box configuration. This functionality _appears_ to be lost with the updated versioning functionality introduced in Aspen. Sys_update_xml now retains only the most recent version of the record (unless there are multiple update sets capturing changes to the same record) and the BaseLine set is gone. The first entry in sys_update_versions is the first modified version of the record, and I haven't been able to locate the out-of-box configuration information for the field for something like a rollback to baseline. Is this information captured somewhere else?

Thanks,
-Brian

[john_roberts]

Aspen also introduced versions as an enhancement to update set records. The versions table will keep a copy of every edit, while the current update set only keeps the latest.
You may need to add the versions related list to your forms if it's not there by default.

[brian-rowland]

John,
Thanks for your response. I took a look at what versions captures on a demo instance last night, and the baseline data still appears to be missing. Here's what I did:
1) Find an out-of-box field with no modifications; no versions, no entry in sys_update_xml. I picked incident.caller_id.
2) Modify the record in some way. I removed the default value script and added a fake attribute.
3) Save
4) A single version entry is created (along with a single entry in sys_update_xml) that contains only the new values. There is no record that the default value field previously called a JavaScript function. As far as I can tell, that baseline information is just gone.

This is an issue because I have a situation where a consultant modified core fields when they shouldn't have. Instead of rolling back to the baseline version like we would have pre-Aspen, we have to go compare the field on a demo instance, get the out-of-box values, and re-apply. This field is now flagged as custom when it shouldn't be.

We also used to have a step in our upgrade process where we identified any records that should be rolled back to baseline, based on the the upgrade results on our dev instance. We then reverted them on our test/prod instances prior to applying the upgrade to reduce the number of skipped upgrade entries on those instances. We'll have to do something different moving forward if we can't get the baseline data until the upgrade is applied.

[john_roberts]

Looks like this is a bug on dictionary updates. Other records I've tested do create a "system" version on the first edit, which is essentially the baseline version. You can use this to compare and restore.
I'll look into the issue with dictionary updates. Thanks for the details.

[brian-rowland]

John, thanks again for your reply. I do see what I believe are the "system" versions for non-dictionary records on a demo instance. All of the business rules have a version w/ the Berlin upgrade as their source. Our Aspen instance does not have these entries for Business Rules, Client Scripts, etc.. The behavior I described for dictionary records appears to true for all record types on an Aspen instance.