## Problem/Motivation Things point at each other across this module and almost none of it is protected. A consumer names the payment account its money lands in; a payment names the consumer it was taken for; a remote and an account each name a `key` entity holding the secret they authenticate with. Any of those can be deleted while the other side still depends on it. Two of the deletions kessai does own are already right, and are the shape the rest should follow: deleting a payment takes its claims, refunds, reversals and metadata with it, because a movement naming a payment that is gone is a record of money nobody can read; and deleting a remote forgets its access token and its notice secret, so removing a host does not leave its credentials behind. ### A consumer can be deleted while payments name it There is no guard of any kind. The payment records the consumer's `client_id` as a plain string rather than an entity reference, so Drupal's own dependency machinery has nothing to object to either. The payments can still be settled — the account settles the money, not the consumer — so what is lost is everything that connects them to the site they were taken for. **Notices stop, without a word.** `PaymentNotifier::findConsumer()` answers NULL and the notifier returns, deliberately without logging: a missing consumer sits in the same branch as one that never said where its site is, and neither is worth a line on every payment. **The consumer site can never read those payments again.** Every read door scopes by the calling consumer, and there is no consumer left to authenticate as. The rows are not orphaned, only unreachable from outside. **And the identity is re-usable.** `ConsumerScope::getConsumerId()` answers the `client_id` string, and that string is the whole of what a payment's `consumer` column is matched against; the entity's own id never enters into it. Delete a consumer and create another with the same `client_id`, and the new one inherits the old one's payments. ### An account can be deleted while a consumer names it `PaymentAccountDeleteForm` counts one thing: `kessai_payment` rows with that account's uuid. Nothing looks at consumers. So the guard only bites once payments exist, and the gap is widest exactly where it matters most — an account a consumer is pointed at but that has not taken a payment yet deletes with no warning at all, which is the freshly configured consumer site before its first checkout. It cannot be fixed where that form lives. `kessai_engine` depends on `drupal:options` and `kessai:kessai` and has never heard of `consumers`, so the form that refuses cannot ask. ### A key can be deleted while a remote or an account authenticates with it A remote holds `client_secret_key`, the id of the `key` entity carrying its OAuth client secret. A Worldline account holds two more in its settings, `secret_key` and `webhook_secret_key`. Deleting any of them is unguarded and silent: the remote stops being able to get a token, and the gateway stops being able to authenticate at the provider or verify a webhook, each at the moment it is next needed. Neither declares a config dependency on the key, and neither should: a dependency would make deleting the key **delete the remote or the account**, which is worse than what it prevents. ## Proposed resolution **A targeted form alter on each delete form, adding a `#validate` callback that refuses.** A validate callback rather than an override, because none of these forms is kessai's to subclass; a targeted alter rather than a global `hook_form_alter`, because every form id is known. | Deleting | Refused while | Guard lives in | | --- | --- | --- | | a consumer | payments name it | `kessai_server` | | a payment account | a consumer names it | `kessai_server` | | a key | a remote authenticates with it | `kessai_client` | | a key | a Worldline account signs or verifies with it | `kessai_worldline` | `kessai_server` takes the first two because it is the only module that depends on both `kessai_engine` and `consumers`, and the one that put the `kessai_account` field on the consumer to begin with. The key guards live with the settings that name the key: the rule is shared and the sentence is not, since naming *which* thing has to be pointed elsewhere is the whole use of a refusal. **Disabling is what retires a consumer, and it has to start meaning something.** The `consumer` entity already carries a `status` field labelled "Enabled", already its `published` entity key, so there is nothing to add to another project's entity. kessai reads it nowhere: a disabled consumer today takes payments, reads them back and is told about them exactly as an enabled one does. **A disabled consumer is refused new payments, and nothing else changes.** It goes on being able to read the payments it already took, and it goes on being told when they move: the money is still its responsibility, and a notice about it is not something to withhold. That is the same rule a disabled account already follows. The handshake asks as well, for the reason it already refuses a retired account: that door exists so an operator finds out while they are looking at a form, rather than saving a remote whose first payment is refused with a payer waiting. ## What shipped - The four refusals above, each as a `#validate` callback added by a targeted form alter. - `ConsumerScope::assertConsumerTakesPayments()`, asked by the two doors that take a payment and by the handshake, and by nothing else: settling, reading, forgetting a token and deleting a payment are all things a retired consumer goes on doing. - Every guard has a test proving the rule, and a second proving it is *connected*: one that submits the form an operator submits. Removing a single `#[Hook]` attribute leaves the rule tests green and the entity deletable, which is the only failure mode that matters here. - `docs/remote.md` says what retiring a consumer means, next to what retiring an account means. ## User interface changes Each delete form refuses while something still depends on what is being deleted, and points at disabling instead where there is something to disable. ## API changes None to `@api` surfaces. `ConsumerScope` gains a method, and it is internal. ## Data model changes None. The payment goes on recording the `client_id` it was taken for. AI-Generated: Yes (Claude Code was used to help draft this issue summary.)