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.