Problem/Motivation
Because of the issues #2977362: Revision user incorrectly appears as anonymous user when node author is canceled and #3089747: Content moderation can wrongly set old revisions as default when they're resaved and our necessity of restrict the cancel options to disable the user instead of delete, it is a good moment to add the ability to choose which options show when cancel an account.
Similar contrib modules:
- Disable user deletion https://www.drupal.org/project/disable_user_deletion/
- Prevent user delete reassing https://www.drupal.org/project/prevent_user_delete_reassign It is only for the option of deleting and reassigning to anonymous.
Steps to reproduce
Delete a user from /user/[UID]/cancel
Proposed resolution
Add the ability to restrict the options cancel user account from the account settings /admin/config/people/accounts
Account settings:

Account cancel page:

| Comment | File | Size | Author |
|---|---|---|---|
| #35 | core-user-cancel-3384789-10_3_x.patch | 8.29 KB | eduardo morales alberti |
Issue fork drupal-3384789
Show commands
Start within a Git clone of the project using the version control instructions.
Or, if you do not have SSH keys set up on git.drupalcode.org:
Comments
Comment #4
eduardo morales albertiReady to review, It needs tests, but we would like to confirm if this solution is good for Drupal and then we will add the coverage.
Comment #5
eduardo morales albertiComment #6
eduardo morales albertiUpload patch with the right Schema
Comment #9
cilefen commentedComment #10
eduardo morales albertiTests fixed, pending to cover with tests the new functionality.
Comment #11
eduardo morales albertiCreated test and solved failed PHPUnit tests, ready to review.
Comment #12
smustgrave commentedTests are looking good.
Think we will need a simple update test though. Something simple like
Check values are null
Run updates
Check values are false.
Rest looks good!
Comment #13
eduardo morales albertiAdded upgrade test checking the new values on user.settings.
Comment #14
eduardo morales albertiReviewing failed tests on Drupal 11.x
Comment #15
eduardo morales alberti@smustgrave Both MR tests passed.
Comment #16
poker10 commentedThanks for working on this @Eduardo Morales Alberti!
I am not sure, that the code is doing what the field description says:
Looking at the changed code:
It seems to me, that the new field can only restrict access in addition to the already set #access property. It cannot explicitelly allow an access to the option if #access is already disabled (so the option will not be displayed). Therefore the field name and description seem to me a bit confusing.
Other thing is that in case you have disabled some options (via
hook_user_cancel_methods_alter), these options will still display in the new field because of this:I think, that this is not good from the usability point of view (and it has no point to allow a user to check/uncheck them, because these will not display regardless of this setting).
Other point is, what will happen if you select a default option in the
user_cancel_method, but you will not enable that method inuser_cancel_methods? Should a new validation be added?Available options can be altered via contrib modules, so I would consider if this change would fit to the core. In case yes, I think that we need a Usability review to check the new field (and its title / description), so we do not create a confusion among users. Thanks!
Comment #17
eduardo morales albertiComment #18
eduardo morales albertiSo after reading the comment from @poker10
The pending tasks are:
@poker10 Did I forget any point?
Comment #19
eduardo morales albertiIf we change the description of the field to "Disable the following cancel methods:", does this fit better for you?
Changing from:
To
Comment #20
eduardo morales albertiReady to review.
Now the options to disable the cancel options are like this:

admin/config/people/accounts
We also added a validation to avoid choosing a disabled user cancel method.
Comment #21
smustgrave commentedProbably can close MR 4683 I don't think non bugs are being backported to D9 anymore.
Reviewing 4684
Applied the patch
Ran updb which ran without issue
Verified the config changes appear when doing a config export
Verified test coverage for post_update is there
Was checking the settings and think a good follow up would be to add states to the cancel methods. For example if I try to check "Disable the account and keep its content." I get an error in "When cancelling a user account" with message "The default user cancel method can not be a disabled method." Tagging for follow up if someone could open that.
But configuration updates work.
Was also still able to cancel an account.
Comment #22
xjmHiding file attachments since the MR work seems most recent. @Eduardo Morales Alberti, for future reference, it's not necessary to post patches on an issue that has a merge request, and mixing the two adds noise and makes the issue harder to review. Thanks!
Edit: I also closed the D9 MR version as suggested.
Comment #24
xjmThanks for your work on this!
It took me a couple reads to understand what this is actually proposing. Posted a few remarks on the MR.
I think #21 needs to be fixed here (with test coverage), not in a followup. Otherwise, we're closing a feature request but opening a bug instead.
Do users see these options when canceling their own accounts, or do they just follow the default option? And if so, should the user be told that?
I've more concerns aside from those I already expressed but out of time for the moment. I think this issue needs framework manager feedback on the correct approach, or whether this is safe or a good idea.
Comment #25
xjmI was thinking about the architectural implications of whether core should allow this configuration, but we could also use product manager feedback on whether this is a suitable feature for core. There's a usability cost to having an extra field every time a user is canceled, as well.
Comment #26
eduardo morales albertiWorking on xjm comments
Comment #27
eduardo morales albertiAll issues were solved, added more testing coverage and validations, ready to review.
Comment #28
poker10 commented@Eduardo Morales Alberti yes, I think the descriptions / labels are better now, thanks!
The MR proposes to hardcode the original four cancellation methods in the
cancel_method_options(inuser.settings.ymlanduser.schema.yml).But it is still possible to modify these methods via hook_user_cancel_methods_alter, so it is possible to add a new method for example. What would happen in that case - would it be possible to disable also such a new method added via that hook?
Comment #29
eduardo morales alberti@poker10 Maybe the property should be a sequence instead of a mapping, reading the documentation about schema I saw this https://www.drupal.org/docs/drupal-apis/configuration-api/configuration-...
#3384789-28: Allow restriction of available User Cancellation Methods on deletion confirmation form
The Account Settings form will also load the custom methods because it calls to user_cancel_methods, if they are not configured, will be shown as disabled, in those cases, we can show them as "Available" to avoid lost methods on the form save, and then let the user chose if checks or not those methods. What do you think about it?
https://git.drupalcode.org/project/drupal/-/merge_requests/4684/diffs#0f...
$form['registration_cancellation']['user_cancel_method_options'] += user_cancel_methods();If the custom method is not configured by the user.settings then the method will be available.
https://git.drupalcode.org/project/drupal/-/merge_requests/4684/diffs#b2...
Comment #30
smustgrave commentedCan this be rebased? Gitlab is saying this is unmergable
Comment #31
longwaveRan into this on two separate sites this week, where content has been deleted in error because users with "administer users" did not understand the difference between the options. Allowing this to be configured in core would be a good step.
However I think the title of this issue is incorrect? Admins can already choose the cancellation method on the user cancel form; this issue proposes a separate option to restrict the set of available options?
Comment #32
lpeidro commentedHello:
I have found two main problems in the patch:
Comment #33
eduardo morales alberti@longwave Title updated.
Fixing merge request issues.
Comment #34
eduardo morales albertiReady to review
Comment #35
eduardo morales alberti@lpeidro
Comment #36
eduardo morales albertiErrors on MR:
PHPUnit:
Comment #37
eduardo morales albertiWe are not able to reproduce the PHPUnit errors on a Drupal 11.0-x-dev locally.
Comment #38
smustgrave commentedappears to have a number of test failures.
Comment #39
eduardo morales alberti@smustgrave What should we change on the MR?
The errors are:
But it is defined by the user.settings install config https://git.drupalcode.org/project/drupal/-/merge_requests/4684/diffs#1e...
We could not reproduce it locally.
Comment #40
eduardo morales albertiComment #41
smustgrave commentedMaybe something in the migration tests need to be updated to be aware of the new keys
Comment #42
eduardo morales alberti@smutgrave it is happening on all types of tests not only on migrations.
Seems related to the schema validation, but the schema seems to be right.
Comment #43
smustgrave commentedAh are there user.settings in any profile or test modules?
Comment #44
eduardo morales albertiThank you! We saw that some profiles have their user.settings like demo umami, we review it!
Comment #45
eduardo morales albertiThe remaining failed tests do not seem to be related to this change.
Any clue?
Failed PHPUnit:Solved after rerun the test.Failed Nightwatch:Solved after rerun the test.Comment #46
eduardo morales albertiAll tests fixed.
Comment #47
eduardo morales albertiFixed MR conflicts.
Comment #48
eduardo morales albertiReady to review
Comment #49
larowlanGreat work here, left a review
Comment #50
eduardo morales albertiPending review PHPUnit test after applying suggestions.
Failing Drupal\Tests\user\Functional\UserSubAdminTest::testCancelAccount
├ Behat\Mink\Exception\ElementNotFoundException: Form field with id|name|label|value "user_cancel_method[user_cancel_block]" not found.
Comment #51
eduardo morales albertiAll threads solved but one, pending to review configuration
Comment #52
eduardo morales albertiAll threads solved!! Ready to review
Comment #53
eduardo morales albertiReverting the latest commit and applying the schema again, as it had too many changes not related to the issue
Comment #54
eduardo morales albertiReady to review!!
Comment #55
eduardo morales albertiComment #56
eduardo morales albertiComment #57
needs-review-queue-bot commentedThe Needs Review Queue Bot tested this issue. It fails the Drupal core commit checks. 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.
Comment #58
eduardo morales albertiUpdated branch and solve bot messages
Comment #59
dcam commentedI took a quick look at the MR and noticed that the new update path test doesn't have the newest attributes. I suggest rebasing it and updating the test.