Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Consider DeleteContentItemVesionAsync content manager method (content item destroy) #6056

Open
deanmarcussen opened this issue Apr 29, 2020 · 7 comments
Milestone

Comments

@deanmarcussen
Copy link
Member

Also discussed as a follow up to recipe idempotancy we could consider a DeleteContentItemVersionAsync method.

This method would be a hard delete, rather than the RemoveAsync which is a a soft delete.

It may need to consider how to handle finding and instigating a promotion to latest or published, if the Version being deleted is published or latest, otherwise the content item would be lost to the admin, it could take options for how to handle this behaviour, or it could be written to noop (with an exception) if the version being deleted is published or latest, so the user could know to find and promote a previous version first.

@jtkech
Copy link
Member

jtkech commented Apr 30, 2020

Maybe 2 methods DeleteAllVersionsAsync() and DeleteArchivedVersions()

@carlwoodhouse
Copy link
Member

I swear there used to be a hard delete called DestroyAsync :/ can't find it though .. recently run into this issue myself. (wanting to hard delete contentitems that dont even use versioning)

@deanmarcussen
Copy link
Member Author

I swear there used to be a hard delete called DestroyAsync :/ can't find it though

I like the name Destroy we should use that ;)

@sebastienros sebastienros added this to the 1.0.x milestone May 21, 2020
@Piedone Piedone changed the title Consider DeleteContentItemVesionAsync content manager method Consider DeleteContentItemVesionAsync content manager method (content item destroy) Apr 28, 2024
@Piedone
Copy link
Member

Piedone commented Apr 28, 2024

We had a destroy operation in Orchard 1.

@ApacheTech
Copy link

I have spoken at length about this option in the past, and I'd like to document my thoughts and feelings here.

From the start, I think it is entirely unsuitable for a CMS of any description to hold your content ransom. With the only way of removing data, to manually pick through the database, deleting records by hand that you just hope are the right ones.

Data Protection / GDPR

When someone invokes their right of erasure, as the data controller, I am duty bound to perform an exhaustive best-effort sweep of personal data pertaining to the data subject. OrchardCore, as a data processor, also has a part to play. There is currently no way to be able to collate, audit, or curate the personal data held by OrchardCore, about the data subjects that we have a duty of care over. The same would be true with the invocation of the right to rectification, or the right to data access.

Cloud Computing

In a cloud environment, where you pay for compute, and for storage space, it is best to keep databases as slimline, and as clean as possible. This also helps with scaling, migration, efficiency, and just basic data quality. Currently, there is no way to prune the database at all. It will only ever grow. There's no undo button, there's no way to get rid of the ever-growing pile of dead-weight that the database becomes. A CMS site that now holds just a single ContentItem for a single page could have a database of over a TB supporting it, just because there's no way to get rid of the redundant mess from content that has since been removed. That site needs nothing apart from a single copy of a single content item, but it could have tens of millions of records in the database, with no way of getting rid of them. This is an extreme, but perfectly viable example. It is the logical conclusion of extended use of the CMS as it stands.

Every single website that uses OrchardCore uses more compute, more storage, more memory, and costs more money than it should do. Purely because this feature has not been implemented.

It needs fixing. As soon as possible.

@Piedone
Copy link
Member

Piedone commented Jul 16, 2024

Related: #16447.

@ApacheTech
Copy link

Ideally, There's be a three pronged solution for this, from a CMS perspective:

  1. You'd have a visible Recycle Bin, where links to deleted records are kept. You can then restore, or permenantly delete records from there.

  2. Also, within the drop-down for each ContentItem, you'd want a "Prune Revisions" option that gets rid of all the previous versions of the content item.

image

  1. And finally, you'd want an option to prune the entire database of anything that isn't currently published. This option would be within the core setting for the site, and would be locked behind a big red button, and a confirmation dialogue.

With these three UI elements in place, the CMS would be useable, long term. For a real-world reference how how these elements can be implemented, please see every single other CMS on the market.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

6 participants