[META][UX][DX] Overhaul User module permissions and the respective admin UI

I started writing all this in a comment in #3511, but it soon became obvious that things would get out of scope, so I moved everything in this meta. So this is all (or mostly) about this bit of the admin UI (/admin/config/people/settings):

TL;DR

This is where I would like us to go ideally:

1. Add a permissions matrix in /admin/config/people/settings, with all user-related permissions. If too overwhelming, then perhaps omit role-specific permissions; move those to /admin/config/people/roles instead.

2. New "Create user accounts" permission (or "Register user accounts"?), to replace the "Who can register accounts" set of radio options.

3. Add a dedicated checkbox for the "but administrator approval is required" bit; enabled by default. Use #states to hide this checkbox + the "Require email verification..." checkbox if the "Create user accounts" permission is not granted to the anonymous role.

4. Make the "Personalisation" fieldset collapsible, and collapse it by default - add a summary/description to it.

Smaller improvements to consider: - Rename "administer" to "manage". Each time I see the word administer, I can't help but to associate it with it's alternative meaning: dispense or apply (a remedy or drug) - Add the word "settings" (or "options"?) at the end of the "Registration and cancelation" fieldset.

The whole story

...let me start by saying that I wish that people added more comments to their code, and made less assumptions about things being obvious (and also used less vague names for variables) . I am finding that the admin UI for this, as well as the code behind it, are very elaborate/complicated/misleading, so both a UX and a DX issue.

So, I was going through the code in user_account_form(), trying to figure out how things work. Here is my understanding of the "internals" of the "Who can register accounts" setting:

• Administrators only: this is not entirely accurate. It actually is all users with the "Administer user accounts" permission.
• Visitors: technically, all people visiting a site are "visitors" (even the logged-in/authenticated ones). This actually means "everyone" or "not limited by any permission/role". Because people that have existing accounts are not allowed to created user accounts (unless they have a role with the "Administer user accounts" permission), this by process of elimination implies anonymous users.
• Visitors, but administrator approval is required: practically the same as the previous option, but all accounts are created with their status set to be blocked/disabled/0.

Please let me know if I have any of the above wrong, or if you have a more detailed/accurate description of what is the technical/dev-orientated description of what is actually happening behind the scenes.

Anyway, if the above are correct, then I have the following thoughts/ideas:

• It seems to me that what we are currently doing is working around some core limitation (most likely inherited by previous versions of Drupal), hence the "disconnect" between what is happening in code vs. what we are communicating via the admin UI. So my take is that there should be a separate permission ("Register user accounts" or "Create user accounts"). Then this series of checkboxes should be changed to a permissions matrix (#3332), via which you could specify various roles which would be allowed to register accounts. This would a) make the "Administrators" setting less "vague", and at the same time b) allow delegating the creation of creating user accounts to other people/roles, in a less "permissive" way, that is obvious to set/overview. There is actually a contrib module that does that (not at all surprised that this thing annoys people the way that is currently implemented): https://www.drupal.org/project/create_user_permission ...but for D7 it requires a core patch to work: https://www.drupal.org/project/drupal/issues/2922852.

• The "but administrator approval is required" bit sounds like it should be a checkbox. In fact, it may not be required at all, if the default would be to always create accounts as disabled/blocked, leaving the "Administer user accounts" permission to control who is allowed to enable/activate user accounts. This would practically mean that when creating accounts ("Create new account" form), the "Status" field should only be available to roles with the "Administer user accounts" permission. Luckily, this is already how things are implemented (user.module, user_account_form()):

  ...
    $admin = user_access('administer users');
  ...
    $form['account']['status'] = array(
      '#type' => 'radios',
      '#title' => t('Status'),
      '#default_value' => $status,
      '#options' => array(t('Blocked'), t('Active')),
      '#access' => $admin,
    );
  

  ...so we basically need to ensure that all accounts are created as blocked by default, unless the user has the 'administer users' permission (in which case, they will be able to set the status via the respective field in the form). Luckily, this is how things are already implemented:

    if ($admin) {
      $status = isset($account->status) ? $account->status : 1;
    }
    else {
      $status = $register ? config_get('system.core', 'user_register') == USER_REGISTER_VISITORS : $account->status;
    }
  

  ^^ we just need to add inline comments in the above code.

• There should be another permission to control assigning roles to users (basically to control whether the "Roles" field in the "Create new account" form is available or not). Luckily, we have already added such a permission in Backdrop core (#313), and that is how things are already implemented (user.module, user_account_form()):

    $roles = array_map('check_plain', user_roles(TRUE));
    $form['account']['roles'] = array(
      '#type' => 'checkboxes',
      '#title' => t('Roles'),
      '#default_value' => (!$register && isset($account->roles) ? $account->roles : array()),
      '#options' => $roles,
      '#access' => $roles && user_access('assign roles'),
    );
  

Tasks

• [ ] #3511 | [UX] Clarify what the anonymous visitors setting will do (do not confuse with role name)
• [ ] #??? | Add a "Create user accounts" permission
• [ ] #??? | [D8] Add a "Manage user roles" permission (https://www.drupal.org/project/drupal/issues/151311)
• [x] #313 | [D8] Create a new 'Assign user roles' permission
• [ ] #??? | [UX] Add all account-related and role-related permissions in a permissions matrix in /admin/config/people/settings