Contrib.social

Make user_cancel() parameters explicit as method on User

Open on Drupal.org →
Created on 15 December 2023, 9 months ago
Updated 17 December 2023, 9 months ago

Problem/Motivation

https://api.drupal.org/api/drupal/core%21modules%21user%21user.module/fu... is highly UI-related through the
array $edit: An array of submitted form values. parameter.

I just wanted to implement a user cancellation based on a third party call, but this would mean I'd have to recreate the $edit array and guess which form values are expected. That seems dirty and dangerous:

user_cancel_delete(['???' => '???'], $uid, 'user_cancel_delete');

Steps to reproduce

Implement a call to user_cancel() and see the dirty requirement to provide an array with not clearly defined values as parameter.

Proposed resolution

Provide a user_cancel() method with clear parameters that can be safely passed from API

Perhaps like this:

$user->cancel($method);

or better if we need different parameters by method:

$user->cancelDelete();
$user->cancelAnonymize();
$user->cancelReassign($otherUser);
// [...]

Remaining tasks

Find out, which values from the $edit parameter are really used
Implement these parameters as real (typed) parameters
Provide an API method, presumably to be called on the user object like ->delete()

User interface changes

API changes

Data model changes

Release notes snippet

📌 Task
Status

Active

Version

11.0 🔥

Component
User module  →

Last updated 1 day ago

Created by

🇩🇪Germany Anybody Porta Westfalica

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @Anybody
  • Comment 9 months ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Comment 9 months ago →
    🇩🇪Germany Anybody Porta Westfalica
  • Comment 9 months ago →
    🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    The reason this is highly bound to the UI is because it uses batch to eg reassign all the content

    If we move it to a method on the user it would have to return a batch array that the caller would need to provess

  • Comment 9 months ago →
    🇩🇪Germany Anybody Porta Westfalica

    Thanks for the quick response and clarification @larowlan! I think that doesn't have to be a blocker.

    This method could be kept for UI-level with batch API but at User Entity level we could implement an API method to handle user cancel like the UI does and not only a "hard" ->delete(). So we have the best of both worlds, what do you think? :)

    Makes tagging this with "API-First Initiative" sense?

  • Comment 9 months ago →
    🇦🇺Australia larowlan 🇦🇺🏝.au GMT+10

    We would need something like a background queue to process the cancellation

    ✨ Provide a Entity Handler for user cancelation Needs work is also related.

    I think if you're using an API, blocking the user is probably the simplest approach as that can be safely completed without batch.

contrib.social Blog FAQ Discussions
Production build 0.71.5 2024