Trash

The Trash panel provides a safety net for deleted items. When topics, resources (CIs), or rules are deleted, their data is moved to the Trash instead of being permanently removed. Administrators can review, restore, or permanently delete trashed items from this panel.

Accessing Trash¶

Navigate to Admin > System > Trash. This panel requires the action.admin.trash permission.

Viewing Trashed Items¶

The Trash panel displays a paginated table of all trashed items with the following columns:

Name - The original name of the deleted item (shown in bold).
MID/ID - The internal MID (for topics and resources) or rule ID.
Type - The entity type displayed as a colored tag: Topic (blue), Resource (green), or Rule (orange).
Collection - The specific collection or rule type (e.g. topic, generic_server, event).
Category - The category name (for topics only).
Deleted By - The username of the person who deleted the item.
Deleted On - The date and time when the item was deleted.

Searching and Filtering¶

Use the search bar to search across name, MID/ID, collection, category, and deleted-by fields.
Use the type dropdown to filter by entity type: All Types, Topics, Resources, or Rules.
Click the Reload button to refresh the table.

Selecting Items¶

The table supports row selection via checkboxes for bulk operations:

Select individual items by clicking their checkboxes.
When all items on the current page are selected and there are more pages, a banner appears offering to select all items across all pages.
Click Clear selection to deselect all items.

Restoring Items¶

Single Item Restore¶

Click the Restore button (undo icon) on any trashed item. The system validates the restore by checking:

The original MID or rule ID is not already in use.
For topics: the category and status still exist.
Related resources (from relationships) still exist.

If validation passes with no warnings, the item is restored immediately.

Dependency Detection¶

When an item has relationships to other items that are also in the trash, the system detects these dependencies automatically. This works in both directions:

Relationships stored in the item's own trash snapshot.
Relationships stored in other trashed items' snapshots (covers the case where the related item was deleted first, which removes the shared relationship record before the current item's snapshot was taken).

A modal displays the validation results:

Restorable dependencies are shown as checkboxes (all checked by default). Each dependency shows its type tag, name, and relationship type. You can uncheck any dependency you do not want to restore.
Non-restorable warnings (e.g. resources that were permanently deleted and are not in the trash) are shown as a bullet list under "The following references will be skipped."

Click Restore to proceed. Checked dependencies are restored first (in date-descending order, so the most recently deleted items are restored first to preserve relationship integrity), then the main item is restored. Unchecked dependencies are skipped and the main item is force-restored, meaning missing references will be ignored.

Bulk Restore¶

Select multiple items using the checkboxes, then click the Restore Selected button (undo icon) in the toolbar. A confirmation dialog shows the count of items to restore. Bulk restore uses force mode, meaning items are restored even if some references are missing. Items are restored in date-descending order (newest deleted first).

Permanently Deleting Items¶

Single Item Delete¶

Click the Delete button (trash icon) on any item and confirm the popover dialog. This permanently removes the trash entry and cannot be undone.

Bulk Delete¶

Select multiple items using the checkboxes, then click the Delete Selected button (trash icon with danger styling) in the toolbar. A confirmation dialog shows the count of items to delete.

Automatic Purge¶

Trashed items are automatically purged by the Purge Daemon based on configurable retention periods. Configure these under Admin > System > General Settings in the Purge section:

keep_trash_topics - Number of days to keep deleted topics in trash (default: 30).
keep_trash_cis - Number of days to keep deleted resources in trash (default: 60).
keep_trash_rules - Number of days to keep deleted rules in trash (default: 60).

What Data is Preserved¶

Topics and Resources¶

master_doc - The CI document with all its attributes.
master_rel - All relationships where the CI is a participant.
master_versions - Version history.
topic - Topic-specific data (for topics only).
reserve_objects - Reserved objects (if applicable).

When a topic is restored, it is "touched" with the current timestamp and the restoring user is recorded as the modifier.

Rules¶

rule - The rule definition including tree, type, and configuration.
scheduler - Scheduler entries linked to the rule.
role_dashboards - Roles that had this rule as a dashboard.
user_dashboards - Users that had this rule as their dashboard.

Note: Compiled rule data (grid) is regenerated automatically when the rule is next saved or compiled after restore.

Restore Behavior¶

When restoring topics or resources, the system checks each stored relationship. If the other side of a relationship no longer exists in the database, that relationship is skipped rather than inserted with a dangling reference. This ensures data integrity even when some related items have been permanently deleted.

Events are emitted during restore (event.topic.restore, event.ci.restore, event.rule.restore) so that the activity log records the restoration.

Limitations on Relationship Preservation

The Trash makes every reasonable effort to capture a complete snapshot of an item and its relationships at the moment of deletion. However, a fully intact restore cannot always be guaranteed, particularly during bulk deletion operations.

When multiple items are deleted together or in rapid succession, the order in which they are processed matters. Each item that is deleted removes its side of any shared relationship records from the database. If item A and item B are related and item A is deleted first, the relationship record linking them is removed as part of that deletion. By the time item B is deleted, that relationship no longer exists in the database, so it cannot be included in item B's trash snapshot.

The system compensates for this by performing a bidirectional lookup during restore validation: it checks not only the relationships stored in the item's own snapshot, but also the snapshots of other trashed items to see if any of them held a relationship back to the item being restored. This recovers many relationships that would otherwise be lost. Nevertheless, there are edge cases, especially in large bulk deletions with complex webs of interdependencies, where some relationships may fall through the gaps and will not be present in any trash snapshot.

In practice, this means that while the Trash provides a best-effort safety net, it should not be treated as a lossless backup mechanism. Administrators should be aware that a restored item may come back without some of its original relationships, and those links may need to be re-established manually.