Permissions

Four, nested, and the nesting is the point.

Why view does not imply strike

Seeing what a deletion would do is a reasonable thing to grant widely. It is genuinely useful: an editor wondering how much of the 2019 archive is still referenced elsewhere can find out without being able to act on the answer, and the preview is read-only in the strictest sense — it runs queries and counts rows.

Doing it is not a reasonable thing to grant widely. So nuke:view is the parent and nuke:strike is a child of it, and granting the parent alone gives somebody the whole plugin minus the ability to break anything.

Why permanent delete is separate again

A soft delete is recoverable for as long as Craft’s trash window allows. A permanent one is not. Those are different amounts of trust, so they are different permissions — and the switch on the strike form is disabled, with an explanation, for anyone without nuke:hardDelete. The server checks it again when the form is submitted.

Users are admin-only regardless

Deleting users cascades into authorship, addresses and permission assignments, and Nuke cannot reassign content the way Craft’s own user delete offers to. So the user scope needs allowUserStrikes switched on in settings and an admin account — nuke:strike alone is not enough.

Settings are admin-only

All three settings screens require admin, as does switching edition. Nothing there is grantable, because the guardrails would not be guardrails if the person they constrain could relax them.

A workable default

On most sites: give editors nothing, give the people who maintain the site nuke:view and nuke:sweep, and keep nuke:strike for whoever would be answering the question if a deletion turned out to be wrong. Add nuke:hardDelete to nobody until there is a specific reason.