Users – system description

Overview

View of the base users: list, form, status, API key, portal link, invitation and password reset. Table names carry the installation's own prefix in the database. Involved: the base user and group tables, user_api_key, portal stores, person (link), user_feature, subscription_account, usage.

Super-admin-only endpoints

user.list, user.form, user.status, user.token and user.tokendelete (API key in user_api_key), user.portalinfo, user.portaldomain, user.portalsend (portal link, store choice, sending via Dlbtmail::dispatch), user.delete. All require isSuper(). Deletion does not delete oneself; with references (getUserLinks) it lists them and refuses; otherwise deleteUser.

Creation (add, SUBSCRIPTION)

1. Permission: canSave($route, 0) → canAction(add).
2. Validation: username at least 3, e-mail, password at least 4 characters.
3. Quota: Dlbtquota::checkAction(creator, 'user/user', 'add', 1) – with need_credit or need_plan an error plus offer data for the modal.
4. addUser() with the posted group, fillUserRoleFromGroup().
5. If the creator has a home client: attachUserToClient() and syncClientPlan(client, creator, new_user).
6. consumeAction(); optional person link (person_id); json.redirect to the form.

Editing and invitation

• edit: canSave($route, id) → canAction(edit); editUser(), on group change fillUserRoleFromGroup().
• invite (user.invite, user.passwordreset, user.inviterevoke): invitation or password reset link by e-mail (Dlbtmail::dispatch), with a log (dlbtlog); revocation invalidates the user's open invitation tokens. Permission: canAction(invite); e-mail and account must exist.

Permissions and limitations

• In the seed list is UNMAPPED and statusdelete BASE – the controller checks neither. edit, invite, debug are not classified.
• Creation does not restrict which user group can be chosen.
• Editing does not check the target user's content scope.