Staff accounts: create a login and set access

Why	Give a team member a way into the system — login, password, rights, visibility — and know the limits (users cannot be deactivated in the interface).
Who	The owner or an administrator, when hiring.
What you’ll get	A working login with the right access group and visibility by category.
Limitations	Users cannot be deactivated in the interface; changing a password requires the current one; there is no “forgot password” recovery on the login screen.

A staff login is created by an administrator — inside the system, by hand: the only confirmed way is to create a login by hand. Accounts live under “System” → “Access (RBAC)”. This article covers creating a user, assigning their group and visibility, what to do about passwords, and which buttons not to look for.

Create a login

1. Open “System” → “Access (RBAC)” → the “Users” tab and press “New user”.
2. Fill in “First name”, “Last name”, “Login” and “Password” — you set the password yourself, by hand.
3. “Email” is optional; the “Property” field is filled in with the current property.
4. Pick the “Access groups”; below sits the “Rooms” scope, for when visibility needs narrowing — more on that below.
5. Press “Save” and hand the login and password to the team member in person.

Result: the team member has their own login and works within the access group you gave them.

The users list has these columns: “ID”, “Login”, “First name”, “Last name”, “Status”, “Actions”; each row offers two actions: “Configure access” and “Reset password”.

Assign a role and visibility

A team member’s rights come from the access group; visibility by room category is a separate scope setting on their card. Both live on the access card: the “Configure access” button in the user’s row.

1. Press “Configure access” — the “User access settings” screen opens.
2. In the “Access groups” field, pick a group — “Manager”, for example. The built-in groups are “Owner”, “Manager” and “Viewer”; in the list they show with their code — “Owner (owner)”.
3. In the “Scope mode” block, keep “All categories” or choose “Selected categories only” and tick the specific ones — a narrow list fits someone who should not see the whole inventory. The hint on the card reads: “The user sees all categories of the selected property.”

Result: rights come from the group, visibility from the scope: a user with rights to rooms sees only the categories you allowed.

Visibility by category belongs to the user, not the role: the role editor has no such setting. What the built-in groups contain, how per-module rights read, and how to assemble your own group — in Roles and permissions: how access works.

Changing a password

A password change also starts in the users list: the “Reset password” button in the row opens the “User password reset” form with three fields: “Current password”, “New password”, “Repeat password”.

The key part: the change requires the current password. Whoever holds the password can change it — the team member themselves, or an administrator who knows it. There is no separate admin reset, and the login screen offers no “forgot password” recovery either: a lost password means a lost way in — it cannot be changed without the current one.

So the rule is simple: keep staff passwords in a password manager from day one.

Interface language and theme

The user card has no language or theme settings of its own. The language switch in the header (Russian/English) and the “Toggle theme” switch are global header controls: every team member picks their own.

What you will not find

The honest boundaries:

• There is no user deactivation in the interface: a departed employee cannot be “switched off” with one button. Access is narrowed by hand — by changing the access group (to “Viewer”, for example) and the password.
• There is no “Role” column in the users list: the role is visible on the card, on the “User access settings” screen.

The log: who did what

Actions around access stay in the log: “System” → “Logs” opens the “Application log” — “View working actions, system events and errors with filters by time, user and entity.”

Access entries are quick to find:

• the USER_CREATED event — a login was created; USER_ACCESS_UPDATED — access was changed;
• the “Access” chip stands among the filter chips;
• who did it — in the “User” column; when — in the “Time” column.

Access is audited: logins created and access changes are recorded with the user and the time.

See also

• Roles and permissions: how access works — built-in groups, per-module rights and custom groups.
• Several properties in one account — how properties work and switching between them.
• How guest data is protected — why limited staff access is part of protecting guest data.
• Support — where to write if something is off with access.