For versioned records, there is no concept of "deleting" the record - it's either being archived, unpublished, or in rare cases removed from draft but left published.
Previously the canDelete() method has been used to check if a record can be removed from draft specifically for versioned records - which is such a rare edge case it almost doesn't bare thinking about, especially given there's no way to do that purely by interacting with the UI, nor with the web API endpoints available in core or supported modules.
Instead, canDelete() is now to be used to check if the record can be archived. This reduces cognitive load for developers and is a step towards simplifying the overly-complex versioning system. This is also in keeping with other mechanisms, such as cascade_deletes which cascades archiving for versioned records.
Note that if the record has stages and is published, we don't allow users to archive if they can't unpublish.
For versioned records, there is no concept of "deleting" the record - it's either being archived, unpublished, or in rare cases removed from draft but left published.
Previously the
canDelete()method has been used to check if a record can be removed from draft specifically for versioned records - which is such a rare edge case it almost doesn't bare thinking about, especially given there's no way to do that purely by interacting with the UI, nor with the web API endpoints available in core or supported modules.Instead,
canDelete()is now to be used to check if the record can be archived. This reduces cognitive load for developers and is a step towards simplifying the overly-complex versioning system. This is also in keeping with other mechanisms, such ascascade_deleteswhich cascades archiving for versioned records.Note that if the record has stages and is published, we don't allow users to archive if they can't unpublish.
Issue