Skip to main content

Users

The Users area is where administrators manage accounts, roles, and identity information for people who access SVRunner.

Who Should Use This Page​

This area is primarily for admins.

Operators usually only need to understand:

  • which account they should use
  • whether they have operator or admin privileges
  • who to contact when access needs to change

What A User Record Contains​

The current user editor includes:

  • first name
  • last name
  • username
  • email address
  • password
  • role

The users table also surfaces:

  • full name
  • username
  • email address
  • role

Users Table Stub screenshot: users table with name, username, email, and role columns visible. Save final image at packages/docs/screenshots/app-users-table.png.

Roles​

The current user model includes two roles:

  • admin
  • user

Admin​

Admins are expected to manage:

  • users
  • preferences
  • licensing
  • extensions
  • systems
  • other deployment-level configuration

User​

Users are the standard operator-level accounts.

They are expected to use the system for routine workflows without broad configuration authority.

Creating A User​

Typical admin workflow:

  1. create the user record
  2. enter the person's identity details
  3. choose a username
  4. add an email address if used operationally
  5. set an initial password
  6. assign the correct role
  7. save the record

Editing A User​

The user sidebar supports updating the same core identity and access fields.

Common reasons to edit a user include:

  • role changes
  • password resets
  • correcting identity information
  • replacing placeholder setup accounts with real named accounts

User Sidebar Stub screenshot: user sidebar showing the identity fields and role selector. Save final image at packages/docs/screenshots/app-user-sidebar.png.

Credential Practices​

Recommended operational practices:

  • avoid shared admin credentials where possible
  • give each person their own account
  • use named accounts instead of generic ones for long-term administration
  • change passwords when staff or access responsibilities change

If the deployment still uses shared operator accounts for practical reasons, document who controls them and when they should be rotated.

Role Assignment Guidance​

Choose the most limited role that still supports the person's job.

Use admin for people who must manage configuration and security-sensitive areas.

Use user for routine scheduling and daily operations unless the site has a clear reason to grant broader access.

Operational Guidance​

Review Admin Access Regularly​

Admin access should be reviewed periodically because it affects configuration, licensing, systems, and account management.

Use Real Names Where Possible​

Using real names in the account record makes audit and support conversations much easier than relying only on generic usernames.

Treat Password Changes As Operational Events​

If an account is used regularly in production, communicate password changes clearly so operators are not locked out unexpectedly.

Common Mistakes​

  • giving too many people admin access
  • leaving setup accounts in place after commissioning
  • using unclear usernames that do not map to real people
  • failing to remove or update access when responsibilities change