The D-07 password-change hook is the existing AccessRevokedEvent, fired
inside the write's transaction by a reset, the user's own change and an
administrator's password; (*AccessRevokedEvent).PasswordChanged reports
those three reasons, and the login rehash fires nothing.
The Users screen declares the record action reset_two_factor (danger)
behind the new permission golem15.users.reset_two_factor, which no role
has by default. It is offered only when a two-factor plugin publishes a
classes.TwoFactorAdmin and the user has a second factor; Run calls the
service's Reset in the action's transaction.
- golem15.users.manage_backend_links (no default role), en and pl labels
- record actions on summercms.cabana.users: link_frontend_account asks for
the frontend user's email (exact, case-insensitive, active users only),
records linked_by and fires the link events; unlink_frontend_account
(danger) removes the link
- a taken or unknown account answers 422 on the prompt
- permissions (the four Winter codes and manage_privileged_groups),
the user navigation item and the embedded admin YAML
- Users controller: list with deactivated users, row states, the
groups, created date and activated filters, and the form's name,
surname and email
- a member of a group in golem15.user.privileged_groups (default
admin) keeps their email, password and row unless the administrator
holds golem15.users.manage_privileged_groups; the refusal is a 403
that saves nothing
