ProfileForm::actions() defines new delete element instead of altering it as it expects

I am not sure whether it is semantically a good idea to replace the canceling with deleting, given that the cancel operation does more than a simple delete.

i tend to agree with dawehner. Maybe we should keep the overriden actions() method and just switch it to a link instead of submit, pointing to the cancel template route

The button on the edit form should definitely use #type 'link' and not #type 'submit'.

However, since these link templates are "global" and also exposed via REST, this requires some more considerations. Technically,

1. The delete operation still exists, but only at the API level. It essentially short-circuits the cancel process to choose the "delete account and all content" method.
2. There is only a form for the cancel operation.
3. There is no form for the delete operation.
4. There is a permission for (A) canceling your own account and (B) canceling other accounts (= "administer users").
5. There is no permission for deleting a user account (unless you count "administer users").

The original plan of #8: Let users cancel their accounts was to remove the "delete" operation entirely for users and only have a "cancel" operation for them.

However, that didn't work so well for API-level operations that really just want to delete an account (e.g. Drush), so #705306: user_cancel_delete method calls into a "standard" user_delete_multiple API re-introduced a parallel "delete" operation, but without a corresponding UI.

I don't know the answer to this problem space, but I hope that this background information is useful.

this is probably enough?

Flagging this as a follow-up for #3258321: Cancel account button on user form triggers server-side validation.

Postponing this on #3258321: Cancel account button on user form triggers server-side validation.. Once that is committed, this issue will need updated/rescoped.

#3258321: Cancel account button on user form triggers server-side validation. has been committed, unpostponing, this issue will also need an update.

Well, here's a patch that changes the user cancel form to a user delete form but having made it I now understand #5 more fully. Semantically it is not a delete form, it's a cancel form.

Personally I think it's better off left alone and maybe apply some credit to #3258321: Cancel account button on user form triggers server-side validation. for work that was done here as patch #6 is basically what happened there?

I was hoping that failure was some weirdness on my local machine. I can't for the life of me figure out why it's failing.

Asked in the #bugsmash slack channel and @acbramley agrees that:

Yeah cancel !== delete for users, in fact deleting is only 1 of the options when cancelling a user

Perhaps if the point is to make things consistent we should make the references to user cancellation more consistent like in this patch?

If we did change the permission it will require an update hook implementation and change record, deprecation etc. I'm just putting this to Needs Review for feedback on whether this is a desirable thing to do, or if maybe we should just close this.

This issue is being reviewed by the kind folks in Slack, #needs-review-queue-initiative. We are working to keep the size of Needs Review queue [2700+ issues] to around 400 (1 month or less), following Review a patch or merge request as a guide.

See [CR TBC]'

Does this need a change record?

Why yes, it does. Here's a draft for review:

https://www.drupal.org/node/3346438

I was waiting to see if there was any feedback on the approach but I guess it's not going to get eyes if it's incomplete.

Change looks good. Even though it's a task wonder if we could add a simple test that if we use "delete" we get the trigger_error correctly.

Yep, good point, this also meant I discovered I hadn't set the error type, so that's done now. Test behaves properly on local so here goes nothing.

Oops, crafted the test patch badly, here's what it should have been.

uploaded patch for 10.1.x.

So, @sun was right in #5 (of course they were). API resources make this a bit of a challenge.

For example in \Drupal\jsonapi\Routing\Routes::getIndividualRoutesForResourceType line 308 we have

$individual_remove_route->setRequirement('_entity_access', "entity.delete");

which sets the route permission for *any* delete operation on an entity.

So we're faced with a few options:

1. Put special cases into the API systems to cater for the "cancel" entity access value, or
2. Instead of deprecating the delete key for users, differentiate between them for API vs Forms, possibly with an additional permission, or
3. Leave well enough alone.

Honestly I'm inclined towards the third option.

Hiding patch from #37 as it regressed functionality, did not apply, has no interdiff, and did not come with any explanation of what it was trying to achieve.

Uploading patch again for 10.1.x after resolvng the errors of custom commands.

Per #39

Thank you for the interest @Ajeet Tiwari but it is expected to test a patch before uploading so have to remove credit for that.

Just FYI to help get the message out there.

Starting March 2023, simple rerolls, rebases, or merges will no longer receive issue credit. Only rerolls that address a merge conflict will be credited, and the merge conflict that was resolved must be documented in the text of an issue comment.
To receive credit for contributing to this issue, assist with other outstanding tasks or unaddressed feedback.
See the issue credit guidelines for more information.

tried to fix the CCF error and to fix the error in #34.

Fixed CCF for #43.

Hiding #43 as there is no interdiff being provided. Also removing credit as it's expected patches to be tested before uploading. #43 appears to be adding additional changes also.

#44 carried forward those additional changes.

Please read #39 before continuing.

@darvanen would agree on option 3 also FWIW