When sending a DELETE request for a user entity (i.e: jsonapi/user/user/{uuid}), the cancel_method setting is honored. This means that unless the cancel method is "user_cancel_reassign" ("Delete the account and make its content belong to the anonymous user"), the DELETE request won't actually delete the user entity but rather block the account.
This is OK and follows the standard Drupal workflow for user deletion.
Nevertheless, when programmatically using APIs, developers usually would want to be able to directly alter entities and could be surprised or annoyed when a DELETE request doesn't actually delete an entity.
For example, think of E2E tests (cypress, mocha): you might want to programmatically create a user for a test and, after the test has run, delete the user.
Or headless Drupal, when the front-end application might want to be able to let a user choose between cancelling the account (without deletion) or deleting the account completely. As it is now, you can't make this distinction from the API.
cancel_method on user.settings is other than cancel_reassignMaybe, for User entities, the body of the DELETE request should be able to include the desired account deletion strategy, one of the following:
user_cancel_block
user_cancel_block_unpublish
cancel_reassign
...alternatively (this is more opinionated), the DELETE request could always perform the actual entity removal or this could be configured as a JSON:API module setting.
This could also belong to a contrib module, of course.
TBD
None
TBD
TBD
TBD
Active
11.0 🔥
Last updated
Considerations of the current setup: #3228000: Users deleted via JSON:API DELETE don't follow the site-wide cancel_method in the user settings → .