Retention, trash & deletion blocks

Three questions, one mechanism: how long data is kept, what happens to something you delete, and how to declare that a particular thing must not disappear regardless of either answer.

They share infrastructure deliberately. One policy table, one background runner, one set of rules — because two cleanup jobs with different ideas about what may be removed will eventually disagree, and the more permissive one wins by deleting first.

Retention windows

Set under Einstellungen → Daten & Fristen by an organization administrator.

Audit retention is unlimited by default, and that is not laziness. The audit log is the evidence of who changed what; an update that quietly started trimming it would destroy exactly what the log exists to provide. Shortening it is an explicit administrative decision.

Shortening a window is confirmed against real numbers. The dialog asks the server what the next run would actually remove under the proposed policy, so the question is "delete 41 200 audit entries?" rather than "are you sure?".

Archived is not deleted

Two different states, kept separate on purpose. Merging them would lose information a restore needs.

A page can be both. Archiving and then deleting keeps the archive marker, so restoring from the trash returns the page archived — the state its author last chose — rather than silently reactivating it.

The trash

Deleting a page or a space is a soft delete. The row survives, disappears from every view, and stays restorable until the window expires.

Deleting a page takes its whole subtree with it, and restoring brings the same subtree back. Anything else would leave child pages stranded under a parent no reader can open.

A deleted page is gone from pages.list, search, backlinks, favorites, subscriptions, tag listings, the dashboard counters, member statistics, space exports, the collaborative editor and the notification digest — every one of them, which is the part that actually takes the work.

Deleted spaces are listed under Einstellungen → Daten & Fristen, not in the space list — a trashed space has no page left to open, so its own settings sheet is unreachable by design.

Deletion blocks (legal hold)

A block is a statement about one object: this must not disappear, whatever window applies. Set it on a page, on a space, or on the whole organization.

It stops everything:

• the audit purge skips rows pointing at the blocked object;
• the trash expiry skips it;
• the manual "delete permanently" is refused;
• and so is an ordinary delete by a user. A block that only halted background jobs would not be a block at all.

Inheritance

A block on a space covers its pages, their comments, their attachments and every audit row pointing at them. A block on the organization covers everything in it.

It also works upwards: a block on a single page prevents its space from being deleted, because the cascade would otherwise take the blocked page with it.

The UI marks blocked objects, and disables the delete affordance rather than letting the click fail. An inherited block cannot be lifted where it is felt — the button says where to go instead.

Setting and lifting

Both are audited, both require a written reason, and lifting is its own event. The legal_hold row is kept after release rather than deleted: that a block once existed, and why it was lifted, is itself evidence.

Related