Create a service for user account cancellation. Convert cancel methods to plugins

This is huge, but I don't see a logical way to split it up to be honest.

This will definitely need subsystem and maybe framework manager review.

Honestly as part of the.module elimination we try to keep our touch as light as possible, but I think this functionality is one of the ones we should update fully.

I took a really high level look and it makes sense to me, but I definitely want to do a deeper review.

The 1st argument seems to me a relic from ancestral Drupal versions.

Yeah, I definitely wouldn't keep it as $edit. It's a Drupal 7 and earlier thing. Renaming should be done, at least, if it's not removed during the changes.

I like that we want to put the cancellation methods into plugins. This makes a lot of sense and allows for way more flexibility when trying to offer other ways of cancellation.

Having said that, the fact that #3043725: Provide a Entity Handler for user cancelation exists must be taken into account here. It's not something we can just fix after this issue lands, only to then realize we made the API hard to work with.

Ideally, we step away from the notion of only being able to choose one cancellation method altogether. Instead, we should have a bunch of granular plugins that do one thing and one thing only, i.e.:

• Block the account
• Delete the account
• Unpublish content
• Reassign content
• Etc.

Then the form should allow you to choose one or multiple actions as you cancel an account. This means we will not have a mess of plugins that are 90% similar but yet slightly different because we needed most of another plugin's behavior with this one special change. We could simply combine the pieces we do want with one custom piece that is specific to our site.

If we were to achieve this, then the entity handler from the other issue could be as simple as checking whether the reassign_content (or whatever) plugin was used, get the necessary metadata from said plugin and go to town. This would work with all possible combinations of plugins and only if you wanted a custom behavior other than reassigning, would you have to overwrite the default entity handler's behavior.

But then you'd fall back into the trap we still have of only one module being able to swap out an entity handler. A problem I have long fixed in Group by making handlers decoratable services. So that won't do either. Which means we'd rather have two methods on an optional UserCancelEntityImpactInterface (or whatever) that the plugins can implement instead:

public function shouldAlterEntities(EntityTypeInterface $entity_type): bool;
public function alterEntities(EntityTypeInterface $entity_type): void;

Now the solution is simple: If a cancel plugin was selected that implements the UserCancelEntityImpactInterface, the entity handler passes its entity type definition to the plugin to see if it's interested. This could be by checking for owner interface, published interface, etc. Then, if interested, do we pass the entity type definition again, allowing the plugin to grab the storage and start doing the heavy lifting.

So, long story short:

1. Plugins must be additive, not mutually exclusive
2. An optional interface must exist, solving #3043725: Provide a Entity Handler for user cancelation
3. I suck at naming things, feel free to improve

To reduce scope creep, we may want to push ahead with the current MR under the following schedule:

• Step 1: Convert current code to plugins like the MR does, leave it at that.
• Step 2: Fix #3043725: Provide a Entity Handler for user cancelation the way I suggested by having these plugins implement an interface and then checking for that. This removes the burden from the entity type modules by centralizing it.
• Step 3: Stop checking for plugin ID as a means to identify cancel methods, rely on interfaces altogether
• Step 4: Now that we have plugins (and people can provide their own) and a way to make plugins act on entities, revisit the idea of making them smaller and easier to work with and rework the UI

I'd love to see a PoC MR on Step 2 as soon as we have a fully reviewed MR here just so we can see if it all works the way we expect before committing to an API here, but that would not be a hard blocker for me as I understand it's asking for even more of people's time. It would be a nice-to-have for sure, though.

Left a couple of suggestions. Feel free to ignore any/all of them.

The Needs Review Queue Bot tested this issue. It no longer applies to Drupal core. Therefore, this issue status is now "Needs work".

This does not mean that the patch necessarily needs to be re-rolled or the MR rebased. Read the Issue Summary, the issue tags and the latest discussion here to determine what needs to be done.

Consult the Drupal Contributor Guide to find step-by-step guides for working with issues.