Users and roles
User accounts are managed in Author → Users, which requires the Admin role.
How much of the account is editable in Dafne depends on how the installation authenticates. Where an external directory is the source of identity, the login and name come from there and Dafne holds only the authorisation.
Contents
Login methods
The login method is determined by the active application profile, not by a setting in the GUI.
| Method | Source of identity |
|---|---|
| Database | Accounts and passwords are held by Dafne. |
| Ldap | Authentication against an LDAP or Active Directory server. |
| Entra | Authentication against Microsoft Entra. |
The login screen and the user menu adapt accordingly: Set password is offered in the user menu only under the Database method.
See Application configuration for how the profile and directory settings are configured.
Fields
| Field | Notes |
|---|---|
| Login name | Alphanumeric characters only, maximum 100. Must be unique. Read-only unless the login method is Database. |
| Full name | Maximum 100 characters. Editable only under the Database method. |
| Password | Shown only when creating a new account under the Database method. For an existing account, use the Change password button instead. |
| Role | One or more roles; see below. |
| Disabled | Blocks the account. Available under the Database method only. |
| Delegated scenarios | Shown only for non-administrators; see below. |
| Description | Free text. |
Roles
| Role | Grants |
|---|---|
| User | Read access. The Monitor, Stats and Visualization screens, and the task hierarchy in the Author module. |
| Admin | Everything, including all Author sections, Bulk and Export, and every action that changes the state of a processing. |
The practical division is that a User can see processing but cannot change it. All of the actions in the Monitor — repeat, cancel, set complete, hold — and all processing actions require Admin, as does control of the executor.
Roles are multi-valued, so an account can hold more than one.
Under the Ldap method, roles are not assigned in Dafne at all: directory groups are mapped onto Dafne roles in the application configuration.
Delegated scenarios
A non-administrator can be given delegated scenarios — a named list of scenarios over which they have rights they would not otherwise hold.
This is how operational responsibility for one part of the workload is handed to the team that owns it, without granting administrator rights over everything. The field is hidden for administrators, who already have access to all scenarios.
User preferences
Each user has preferences stored against their account, saved with Save preferences in the user menu. These are display choices rather than permissions — for example whether disabled items are hidden in the Author tree by default, and the export options last used.
Practical notes
- Prefer disabling to deleting where an account is referenced in history. Disabling blocks access while preserving the record of who did what.
- Grant Admin sparingly. Because every state-changing action requires it, there is a temptation to give it to all operators. Delegated scenarios are the better instrument where the need is limited to one area.
- Under LDAP or Entra, manage membership in the directory, not in Dafne. Changes made here will be at odds with the source of truth.
