## Problem/Motivation [#3621938](https://git.drupalcode.org/project/kessai/-/work_items/3621938) refuses four deletions that would leave something behind unable to work: a consumer payments name, an account a consumer names, and the keys a remote and a Worldline account authenticate with. Each refusal is a `#validate` callback on the delete form. That covers the operator, and only the operator. Nothing reaches those callbacks when the deletion never renders a form: - `$entity->delete()` from any module's code, update hook or cleanup. - A configuration import removing an account, a remote or a key. - Views Bulk Operations, a migration, a Drush command. The account's older refusal, the one that counts payments in `PaymentAccountDeleteForm::buildForm()`, is weaker still: it is build-time, so it swaps the confirm question for an explanation and offers no button, and a submission that never rendered the form is not refused at all. None of this loses money. It loses the ability to move it: an account is what every payment naming it is captured, refunded and reconciled through, and a key is what its owner authenticates with. ## Proposed resolution **Keep the form refusals and put a backstop under them**, rather than replacing one with the other. The form is where a person is told what to do instead, in sentences; the backstop is what makes the answer true whoever asks. `hook_ENTITY_TYPE_predelete()`, throwing. `EntityStorageBase::delete()` invokes it before `doDelete()`, so nothing has been written when it raises, and unlike the entity class's own `preDelete()` it can be implemented for an entity another project owns - which matters here, because three of the four are `consumer` and `key`. Core does exactly this where a deletion must not happen: `ConfigurableLanguage::preDelete()` throws `DeleteDefaultLanguageException`, and `Workspace::preDelete()` throws for a workspace that is still being deployed. Both throw a named exception rather than a generic one, which is what lets a caller that knows better catch it. **The rule has to live in one place per guard.** A form callback and a predelete hook asking the same question in two bodies is the same rule twice, and they drift. Each guard becomes one method answering "what still depends on this", with the form callback turning its answer into a sentence and the hook turning it into an exception. **Move the account's payments refusal to the same shape** while doing it, so all five refusals answer the same way rather than one of them being build-time. ### What this is not An access handler, or `hook_entity_access()` for the delete operation, would hide the Delete link and 403 the route. That is a nicer front door and it closes nothing: `$entity->delete()` never consults access. A config dependency is the other tempting answer and is worse than the problem. Declaring one from a remote to its key, or an account to its own, means deleting the key **deletes the remote or the account** - which is why [#3621938](https://git.drupalcode.org/project/kessai/-/work_items/3621938) refused rather than depended. ## Remaining tasks - One method per guard answering what depends on the thing being deleted, called by both entry points. - `hook_ENTITY_TYPE_predelete()` for consumer, payment account and key, throwing a named exception. - The account's payments refusal moved onto it. - A test per guard that calls `$entity->delete()` directly and asserts it raises and that the entity is still there. The form path already has its own. ### Settled while doing it A delete of several entities at once walks them grouped by class, and each group's `doDelete()` runs before the next group's `predelete`, so in principle a mixed bulk delete can remove an earlier group before a later one refuses. It cannot here. Within one group every `predelete` runs before that group's `doDelete()`, so a refusal on any one entity aborts before any of them is written. Reaching two groups needs two entity classes in one entity type, and none of `consumer`, `kessai_payment_account` or `key` has bundle classes. `consumer` is a content entity anyway, so its whole delete is transactional. ## User interface changes None. The operator meets the same refusal, in the same words, on the same form. ## API changes One named exception, `Drupal\kessai\Exception\DeletionRefusedException`, carrying the entity whose deletion was refused. One rather than three because what a caller wants to know is that kessai refused, and the entity says which thing more precisely than a class name would. It extends `EntityStorageException` and ships a static `inside()`, because the refusal does not always arrive as itself: content entity storage deletes inside a transaction and rewraps whatever comes out of it, so a refused consumer arrives as a plain `EntityStorageException` with the refusal inside it, while a refused account or key arrives as the refusal. Which shape a caller gets depends on the entity type's storage handler, so `inside()` walks the chain and answers either way. ## Data model changes None. AI-Generated: Yes (Claude Code was used to help draft this issue summary.)