What can be undone¶

The rule a grant relies on: an editor can change anything they can reach, and every change they can make can be put back. Before widening what a grant covers, check the new thing against this table.

Operation	Reversible?	How
Editing an article	Yes	Every save snapshots the article first into `article_revisions` — title, summary, content, sections, references, status, note. The revisions panel restores any of them, and restoring snapshots the current state too, so a mistaken restore has a way back.
Editing a question	Yes	`question_versions`, same idea.
Deleting an article	Yes	Soft: `deleted_at` is set and the article moves to the bin in Editorial; Restore puts it back as it was. An article that was never published (`first_published_at` is null) is deleted outright — nobody ever saw it.
Deleting a question	Yes	Soft: `deleted_at` set. The row and its id survive, so anything pointing at it can be put back.
Removing a figure (a grantee)	Yes	A grantee always unlinks: the markdown line and the article's claim on the picture go, the image stays live in the library. The article is snapshotted, so a restore brings the figure line back.
Binning a figure (a moderator)	Yes, for 30 days	`keep_asset=false` strips the figure line from every article that carried it and sets `deleted_at` on the asset. Restoring within the window re-appends the figure line to every section it used to be in.
The daily purge	No	`purge_trashed_media` runs daily and removes the stored object for any asset binned more than 30 days ago. The bucket is not versioned. This is the only scheduled job in the system that destroys anything.
Unlinking a question from an article	Partly	Moderator-only. Re-linking restores it exactly — the row holds no content, only the pair — but nothing records that it existed, and revisions do not capture links. There is no undo and no list of what was unlinked. If the link came from an `article_topic_claim`, re-syncing the claim puts it back; dropping the claim is how you stop that.
Deleting a category, library or deck	Check first	These cascade. `question_article_links`, `article_topic_claims` and grants are `ON DELETE CASCADE`.
Deleting a study plan	Blocked	A `before_delete` listener refuses every path except the explicit admin route. Retire a plan by setting `is_published = 0` instead.

Anything not in this table and not obviously soft is a nightly database dump away: /home/danvics/docker/db-dumps, taken before each Borgmatic run. See Backups and restore.

The two-stage delete, precisely¶

Deleting a figure has two distinct meanings, and the query parameter picks which:

DELETE /api/v1/articles/{article_id}/figures/{asset_id}?keep_asset=true|false

keep_asset=true — unlink only. This article's ArticleMedia claim and its markdown image line go; the asset row and the stored bytes are untouched and the picture stays findable in the library. A non-moderator's request is forced to this regardless of what was sent.
keep_asset=false (the default, moderators only) — additionally bin the asset. The figure line is stripped from every article that carried it and deleted_at is stamped. No bytes are removed at this point. The image sits in the 30-day bin at /media/trash and can be restored.

Bytes go only when purge_trashed_media next runs and finds the asset older than TRASH_DAYS = 30.

Why a grantee cannot bin a picture¶

An article grant is a grant over what the article says, not over the library the picture lives in. The same photograph may be hanging on four other articles, in a library the grantee holds no claim on. So a grantee unlinks and a moderator bins, and the forced keep_asset=true is what makes that true at the route rather than only in the interface.