Deleted Items

Cloud CMS provides a "copy on write" mechanism for any creates, updates or deletes to the content in a branch. This means that whenever you delete something, you're actually masking it as deleted. The content itself is never destroyed or removed permanently.

As such, it is always possible walk backwards in time and discover content that was deleted - all the way back to the moment when your branch or repository was created.

To make things easier, Cloud CMS provides a "deletions" index that it automatically maintains per-branch so that you don't have to manually walk the changeset history. This effectively works like the Mac Trash Bin or the Windows Recycle Bin. It's a place where deleted items are stored, where you can inspect them and where you can restore from should you wish to.

Browsing

Deleted Items are available on the left-hand menu within the Cloud CMS user interface.

This will bring you to a page that lists the deleted items. You can adjust how many to view and also select whether you wish to see nodes or nodes + associations.

Depending on what roles you have, you may be able to do the following:

• Purge a deleted item
• View a deleted item in the API
• Restore a deleted item to your branch

Purge a Deleted Item

This action will remove the deleted item from the deleted items index. Removing it from the index removes it from the list of deleted items. That said, it doesn't actually purge the data from the underlying changeset history.

As such, Cloud CMS always allows you to go back in time to get at data as it once was. This is because of its "copy on write" nature. You're always able to get back previous content should you need to.

View in API

This action will pop open a new browser window with a link to the deleted item in the API. This is mostly available to assist content managers or developers who may be interested in the underlying JSON or binary attachments - all of which can be inspected, retrieved or manipulated through the API.

Restore a Deleted Item

This action will find the deleted node in the changeset history and undelete it. Undeleting the node causes a new node to be written onto a new changeset which is a continuation or undelete of the previously deleted node. In other words, the undeleted node will be a flowing continuation of the lifecycle of the previous node. It will have the same node ID and be a continuation of what once was.

Restored nodes are restored essentially as they were although the form will allow you to adjust the title and/or description. Nodes are restored standalone which is to say that they are not connected to the content graph.

Any associations that the node may have had to the graph will need to be reinstated manually. The undelete process cannot guarantee that restored associations would be consistent or validate given interim changes to your content model, behaviors or relationships to other nodes in the graph.

Undeleting an association requires that the source and target node of the association exist. If they do not, an error will be raised to indicate that they must be restored first.