Remove canArchive() method for CMS 6

[GuySartorelli]

When calling delete() on a record (without changing what versioned state you're operating in), the record actually ends up being archived. While it is more correct to call doArchive() instead of delete() if you intend to archive the record, it's not uncommon to just call delete() directly.

Because of this, it's easy to call canDelete() as the permission check before archiving a record, forgetting that there's a specific canArchive() method that should be called instead.

This has lead to at least one issue in the past.

We should consider whether to remove the canArchive() permission method, and just assume that canDelete() is always canArchive().

Note

• DataObject::delete() and Versioned::doArchive() methods are not being changed

Acceptance criteria

• canArchive() method is deprecated in CMS 5
• canArchive() method is deleted in CMS 6
• Code in updated to use canDelete() in CMS 6

CMS 5 PRs

• API Deprecate Versioned::canArchive() #461
• ENH Don't emit deprecation warnings for unavoidable API calls silverstripe-asset-admin#1483
• ENH Don't emit deprecation warnings for unavoidable API calls silverstripe-cms#2985
• ENH Don't emit deprecation warnings for unavoidable API calls silverstripe-linkfield#319
• ENH Don't emit deprecation warnings for unavoidable API calls silverstripe-elemental#1233

CMS 6 PRs

Important

Don't merge these until the CMS 5 PRs have been merged and merged up.
If there are merge conflicts (which there almost 100% will be) reassign to Guy to resolve.

• API Delete deprecated canArchive method #460
• FIX Use canDelete, not the now-deleted canArchive silverstripe-asset-admin#1482
• FIX Use canDelete, not the now-deleted canArchive silverstripe-cms#2984
• FIX Use canDelete, not the now-deleted canArchive silverstripe-linkfield#318
• FIX Use canDelete, not the now-deleted canArchive silverstripe-elemental#1232
• DOC Document the changes to canDelete() and canArchive for versioning developer-docs#551