Deleting and restoring documents – system description
Status-based deletion and restore, permanent deletion with share confirmation and storage clean-up, the permission keys and the scope gap.
A document can be deleted by status (status = 9, record and file stay) or permanently (record, placements, physical file and cache). Both refuse documents linked to an object.
Data model
Table names carry the installation's own prefix in the database.
| Table | Role |
|---|---|
doc | status (1 = active, 9 = trash) |
doc_link | blocking reference |
doc_share_item | share membership (confirmation, detaching) |
doc_location | additional placements |
Process
statusdelete: refuses a document linked to an object (error_referenced), otherwisestatus = 9.statusrestore: 9 → 1, only for users who see the trash (canSeeDeleted(document)).delete: refuses on object links; for a document in a share folder it first lists the folders and asks for confirmation (need_force), withforce=1it detaches; orphan share rows are cleaned silently.- Then
purgeStoredDoc(): Drive file (to the bin or permanently –removeFile), shortcuts of further placements, OneDrive or local file; placement rows, record and the whole cache (purgeDoc). A physical delete error does not stop the record deletion (logged).
Permissions
- The interface shows one red bin (
i-del) with thestatusdeleteright; users who also havedeleteget a separate "Delete permanently" item. statusdelete: BASE; single and count-based bulk right;docIdInScopeper document.delete: not classified in the seeds.
Known limitations
Permanent deletion (delete()) does not check the content scope.