1.1 Purpose

• Unlimited ad-hoc roll-back to previous version of an item for versioned items
• Work on a new version without impacting the currently published item
• Audit changes by author, date/time
• Stage changes for approval and review

1.2 Operation

Not all content can be versioned.

For example:-

• customer information
• content where it is preferable to have changes visible instantly
• content where there is no reason to track or stage changes

Content can be related to versioned contented. The relationship will always point to the version of the item which is appropriate from the users perspective.

The latest published (and approved if work-flow is enabled) item on the live site

The latest version of the item (or latest published item if work-flow is enabled) on the stage site

1.3 Technical

For each row in a table there is a corresponding row in Aurora_Data which is used to track the author, time/date, status, security and approval status of the item.

When an item is versioned, a new table row is created. A corresponding new row is created in Aurora_Data. The new row is then considered the current item.

When an item is published, it is also versioned. The old row is considered to be a prior version, and in the case of an old published item, an expired old version.

When browsing items, the Aurora_Data table is crucial to identifying which items should be displayed.

 

Infomaxim Aurora can handle relationships to content items which are versioned through the use of bridging indexes, which act as a pointer between the reference to an item (which remains static) and the current version of an item (which constantly changes).

Variables required by the versioning function:-

id         integer              PK of Aurora_Data                  required for updates / empty for inserts