Users — Registration and Access Identifiers
Managing access accounts should not require a ticket or a command line. On the screen (?view=usuarios in the shell) you register, search and adjust each team member's profile and permissions in seconds, with validation before submission and clear messages whenever something does not add up. This page explains an account's three identifiers, how a person signs in, and what happens to accounts created before the login field existed.
Identifiers: name, e-mail and login
Each user has up to three identifiers, with distinct purposes:
| Field | Required | Purpose |
|---|---|---|
| Name | yes | Display in the interface (avatar, listings, audit trail). Does not authenticate. |
| yes | Canonical account identifier — uniqueness key, reference for the API's administrative operations and for mirroring into the platform's identity registry. | |
| Login | yes (local registration) | Short access identifier (e.g. jsilva). Lets the user sign in without typing the e-mail. |
Login rules
- 3 to 64 characters: letters, digits, dot, hyphen or underscore, starting with a letter or a digit (pattern
^[a-z0-9][a-z0-9._-]{2,63}$). - Normalized to lowercase; uniqueness is case-insensitive and checked at registration time.
- Never contains
@— that is how the platform distinguishes e-mail from login in the same Usuário field of the "Entrar no DATTA" dialog. - Required for local registration: without it, registration is refused with the message "Login é obrigatório". Users created through an external provider (Microsoft/Google) receive a login through the automatic fill described below, but keep authenticating through the provider.
Existing accounts get a login automatically
Accounts created before the field existed receive a platform-generated login with no action on your part, on the first startup after the update: a handle derived from the display name — lowercase, accents stripped, separators become dots ("José Rodrigo" → jose.rodrigo) — falling back to the e-mail prefix, with a numeric suffix on collision (jose.rodrigo2).
The routine is idempotent: it only fills accounts that have no login, and accounts that already have one are left untouched. It also establishes, in one go, the login uniqueness constraint. The assigned login appears in the user listing and in the platform's operation log, in the form Backfill de login: <email> → <login>.
Signing in with e-mail or login
In the "Entrar no DATTA" dialog, the Usuário field accepts e-mail or login — whichever the person prefers. The platform resolves the login to the account through a two-tier cache (process memory plus the distributed cache, with dedicated indexes by e-mail and by login — datta:auth:email:{email} and datta:auth:login:{login} — and a 15-minute lifetime), falling back to the datta system database (:Usuario node, login property) when the cache does not hold the account.
On a wrong credential the message is always the same ("Credenciais inválidas"), whether the identifier or the password was wrong — a deliberate protection against account enumeration.
Worked example — registering a new analyst
- In , open the Novo Usuário dialog.
- Fill in the full name (e.g. "Juliana Silva"), the login (e.g.
jsilva), the e-mail (e.g.juliana.silva@empresa.com) and the initial password, at least 8 characters long. - Confirm the registration. The screen itself validates before sending: a blank field, a malformed e-mail, a password outside the accepted length or an off-pattern login is flagged right away, with no round trip to the server. The server then repeats every validation — format and uniqueness — and, if something does not pass, returns the error field by field, shown in the screen's notice.
- Next, assign the base profile (role) and, if needed, the account's direct permissions. Each profile is detailed in roles and permissions.
Day-to-day management
- Search: the listing search filters by name, e-mail, login or job title.
- Check: the user detail shows the login next to the e-mail, when present.
- The login is final: it cannot be edited through the interface after registration.
Profiles and permissions in depth — including creating your own profiles — are covered in the roles and permissions guide. User registration, authentication and the administrative account operations (read, update, delete, setting the profile and granting direct permissions) are also available through the API for automated provisioning: see the API reference.