[Epic] Deletion vs disabling/unlisting

This describes when and how extensions and their version can be deleted or unlisted. For the most part, this is **not** how things work currently: originally, soft-deletion was assumed pretty much everywhere on the back-end, but now there are more and more use-cases that show that it's more trouble than it's worth. The purpose of this issue is to track progress, related PRs and relevant discussion of the topic. ### Terminology: * _soft-deletion_ : all related records remain in the database, but get their `date_deleted` field set to the date of deletion, which excludes them from all queries except for /admin/; * _archiving_ : all related records move to another set of tables (`archive_{extension,version,file,etc}` ?), which staff can view (or delete from) via the /admin/; * _unlisting_ : changing status of an extension or version in a way that it is no longer publicly visible on the website or in the API response; * any deletion, soft-deletion, archiving action always cascades to its dependent data: * deleting a version means deleting its file and its ratings; * deleting an extension means deleting all its versions, preview files, activity and reports; ### From the point of view of staff with delete permissions: - [x] Any "Delete"/"Delete selected" means true deletion, no implicit soft-deletion anywhere in Django admin. Hence, delete permissions should be given out sparingly. ## Extensions TLDR; extensions are not soft-deleted: they are either truly deleted or change their status becoming unlisted. ### From author's point of view: Authors can delete their extensions: - [x] If an extension was never published, it can be **deleted** https://projects.blender.org/infrastructure/extensions-website/pulls/81 . * The `slug` and `extension_id` can be reused; * Any version file can be re-uploaded; - [x] If there was approval queue (or suspicious) activities, we want to keep an archive https://projects.blender.org/infrastructure/extensions-website/pulls/84; * Only admins need to access this. - [ ] If an extension was published, it can only be **disabled**. * The `slug` and `extension_id` cannot be reused. * None of the version files can be re-uploaded; ### From moderator's point of view: For now, we assume that unlisting an already public extension is a drastic measure that won't be needed often, hence we also assume that moderators don't have to be able to delete or disable extensions. ### From admin's point of view: * If something is wrong with an extension, it can be **disabled**; - [ ] If something is very wrong with an extension, it can be **blocklisted**; - [ ] (?) offending file is moved to a non-public storage or simply deleted. ## Versions **N.B.**: versions don't have statuses, their files do: when a version needs a change of status, its file changes status. ### From author's point of view: This should probably work similarly to extensions (in terms of UI as well), meaning that authors can delete their extension's versions: - [x] If a version was never published, it can be **deleted**. * The `version` can be reused; * The version file can be re-uploaded; - [ ] If a version was published, it can only be **disabled**. * The `version` cannot be reused; * Version file cannot be re-uploaded; Currently, subsequent version uploads don't go into the approval queue, so, technically, the only case when a version "was never published" is when an extension is still a draft. ### From moderator's point of view: For now, we assume that unlisting an already public file is a drastic measure that won't be needed often, hence we also assume that moderators don't have to be able to do that. ### From admin's point of view: * If something is wrong with a version file, that file can be **disabled** ; ## Additional considerations: * How should we handle storage? Out-of-the-box, Django doesn't physically delete files when their records are deleted. - [x] files that are deleted need to be deleted from storage ( https://projects.blender.org/infrastructure/extensions-website/commit/845888180baf2d8e6ac401ab5613a7c15e108697 ) - [ ] files that get certain statuses (**blocklisted**) need to be deleted from storage * When an author disables an extension or file, do we show this in public approval activity? * Disabling should require a comment describing a reason

Anna Sirota commented

2024-04-16 17:30:43 +02:00

Owner

This describes when and how extensions and their version can be deleted or unlisted.
For the most part, this is not how things work currently: originally, soft-deletion was assumed pretty much everywhere on the back-end, but now there are more and more use-cases that show that it's more trouble than it's worth.
The purpose of this issue is to track progress, related PRs and relevant discussion of the topic.

Terminology:

soft-deletion : all related records remain in the database, but get their date_deleted field set to the date of deletion, which excludes them from all queries except for /admin/;
archiving : all related records move to another set of tables (archive_{extension,version,file,etc} ?), which staff can view (or delete from) via the /admin/;
unlisting : changing status of an extension or version in a way that it is no longer publicly visible on the website or in the API response;
any deletion, soft-deletion, archiving action always cascades to its dependent data:
- deleting a version means deleting its file and its ratings;
- deleting an extension means deleting all its versions, preview files, activity and reports;

From the point of view of staff with delete permissions:

Any "Delete"/"Delete selected" means true deletion, no implicit soft-deletion anywhere in Django admin.
Hence, delete permissions should be given out sparingly.

Extensions

TLDR; extensions are not soft-deleted: they are either truly deleted or change their status becoming unlisted.

From author's point of view:

Authors can delete their extensions:

If an extension was never published, it can be deleted #81 .
- The slug and extension_id can be reused;
- Any version file can be re-uploaded;
- If there was approval queue (or suspicious) activities, we want to keep an archive #84;
  - Only admins need to access this.
If an extension was published, it can only be disabled.
- The slug and extension_id cannot be reused.
- None of the version files can be re-uploaded;

From moderator's point of view:

For now, we assume that unlisting an already public extension is a drastic measure that won't be needed often, hence we also assume that moderators don't have to be able to delete or disable extensions.

From admin's point of view:

If something is wrong with an extension, it can be disabled;

If something is very wrong with an extension, it can be blocklisted;
- (?) offending file is moved to a non-public storage or simply deleted.

Versions

N.B.: versions don't have statuses, their files do: when a version needs a change of status, its file changes status.

This should probably work similarly to extensions (in terms of UI as well), meaning that authors can delete their extension's versions:

If a version was never published, it can be deleted.
- The version can be reused;
- The version file can be re-uploaded;
If a version was published, it can only be disabled.
- The version cannot be reused;
- Version file cannot be re-uploaded;

Currently, subsequent version uploads don't go into the approval queue, so, technically, the only case when a version "was never published" is when an extension is still a draft.

For now, we assume that unlisting an already public file is a drastic measure that won't be needed often, hence we also assume that moderators don't have to be able to do that.

If something is wrong with a version file, that file can be disabled ;

Additional considerations:

How should we handle storage?
Out-of-the-box, Django doesn't physically delete files when their records are deleted.
- files that are deleted need to be deleted from storage ( 845888180b )
- files that get certain statuses (blocklisted) need to be deleted from storage
When an author disables an extension or file, do we show this in public approval activity?
- Disabling should require a comment describing a reason