-
Notifications
You must be signed in to change notification settings - Fork 2.4k
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
Comments
Maybe 2 methods |
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) |
I like the name |
We had a destroy operation in Orchard 1. |
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. |
Related: #16447. |
Ideally, There's be a three pronged solution for this, from a CMS perspective:
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. |
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.The text was updated successfully, but these errors were encountered: