App users, roles, and runtime-page sign-in

An App user answers “who is operating this App now?” Users, roles, and sign-in state belong to the current App. They identify the operator and determine which Page content is visible or interactive.

This page covers only users and roles inside an App. To choose another account domain, start with Account and permission boundaries.

Current permission model

• A new App contains only the non-removable system Admin role. It has no default App user or password and explicitly enables Allow Guest.
• Each App user has exactly one role and can be enabled or disabled independently.
• With Allow Guest enabled, the unsigned identity has the fixed Guest role. With it disabled, the runtime Page requires App-user sign-in first.
• A missing allowGuest property is treated as disabled; access is no longer inferred from whether any user is enabled.
• An App Admin matches every role inside the current App but receives no permission outside that App.
• Components that support role control can use the current App user to decide which content is visible or interactive.
• Page visibility adjusts the UI experience only. It does not replace authorization owned by an Object, Query, file operation, or equipment action.

Configure App roles

Use roles for stable responsibilities rather than individual names. For example:

Role ID	Display name	Responsibility it can express
Operator	Operator	Routine viewing and operation
Supervisor	Supervisor	Approval and parameter confirmation
Maintenance	Maintenance	Diagnostics and maintenance entry points
Admin	Administrator	Every role branch inside the App

1. Open Settings → Users / Roles in the current App.
2. Under App Roles, select Add Role.
3. Enter a unique, stable Role ID and then a readable name.
4. Keep the system Admin role. Its ID cannot be changed and the role cannot be deleted.
5. Select Save.

Components use the Role ID for permission decisions. A display name can change independently, but after changing a Role ID, inspect every Component permission and related advanced source reference. See Advanced: Page source development for source usage.

Guest is the platform-reserved unsigned role and cannot be added to the role list. If the App must reject unsigned access, turn off Allow Guest at the top of the Page. At least one App user must be enabled before Guest access can be disabled.

Configure Component permissions

Select a Component that supports role control on the Page, then configure allowed roles and unauthorized behavior in Inspector's Permissions section.

• An empty Allowed roles list permits every identity that may enter the App, including Guest when enabled.
• With multiple roles, any match is enough; Admin is always allowed.
• Hide when unauthorized removes the Component and is the default.
• Disable when unauthorized keeps the Component visible but prevents interaction inside it.

Keep CurrentUser outside any region that its own role rules could hide so users can always switch accounts. These settings control UI behavior only and do not replace authorization for sensitive operations. See Advanced: Page source development for permission forwarding in a custom Component.

Move users before deleting their role

When any user still belongs to a non-system role, deleting that role fails. Move those users explicitly to their intended roles, then delete the unused role.

Create App users

1. Stay in Settings → Users / Roles, go to App Users, and select Add User.
2. Enter a unique username and a non-empty password.
3. Assign one role to the user.
4. Leave Enabled on, or turn it off to prevent this user from signing in.
5. Select Save.

A new user requires a password. When editing an existing user, leave the password field empty to keep the existing password or enter a new one to replace it. Theseus currently requires only a non-empty password, but production deployments should follow your organization's strong-password and secure-delivery policies.

Saving updates only the project. To make new users and roles available on a runtime page, Stop the App, run Build, and then Start it. Delivering a new version ends existing App-user sessions, so users must sign in again.

Add CurrentUser to a Page

Add the CurrentUser Component to a Page that should show the current operator or offer account switching.

CurrentUser displays the current App user and opens the shared account window for sign-in, switching, and sign-out. With Guest access enabled, unsigned state is Guest; signing in selects the account's role, and signing out returns to Guest. Identity changes reload the current Page's business content and role checks without reloading the entire application window. Runtime Pages use App login; Design and Snapshot retain the author view.

With Allow Guest disabled, the runtime Page shows App login before loading business content or data. Initial sign-in works even when the Page has no CurrentUser Component. Session expiry or sign-out returns to login. Signing in again restores the requested Page; failed start, equipment-control, or other operations are never retried automatically and must be performed again by the user.

The signedOutLabel, showRole, and showIcon props control the identity button. Account forms use the interface language; the former labels dialog-text prop has been removed. See Advanced: Page source development when writing source directly.

CurrentUser manages only users owned by the current App. Keep it easy to find and outside role-restricted content so the operator can always sign in, switch, or sign out.

Verify the configuration

After deployment, verify at least these scenarios:

Scenario	Successful result
Guest is allowed and no user is signed in	The Page opens and the current role is Guest
Guest is not allowed	An enabled App user must sign in before the Page opens
A regular App user signs in	CurrentUser shows the correct name and role; permissions match only that role
An App Admin signs in	CurrentUser shows the App administrator; every role check inside the App passes
A user is disabled	That user cannot sign in again and an existing identity is no longer valid
A password or role changes	After redeployment and sign-in, the new configuration is used and the old App-user session is no longer valid
The current role is not allowed by a Component	It is hidden or disabled according to the selected behavior, without restricting the CurrentUser entry point

Verify role branches on a real runtime Page rather than Design. Design can help check interactions early, but the final result must use a real App-user sign-in on the runtime Page.

Common issues

Users were saved, but the runtime Page did not change

The runtime Page is still using the previous version. Stop the App, Build again, and then Start it. Saving users in Settings alone does not refresh the delivered version.

A new user cannot sign in

Confirm that the user is enabled, the username matches exactly, and the App was Built and Started after the last change. To replace the password, enter a new one under Settings → Users / Roles, then deliver with Stop → Build → Start.

Settings cannot be saved after Allow Guest is turned off

Disabling Guest access requires at least one enabled App user. Create or enable a user first, then save and Build again.

Page content is wrong after a role change

Confirm that the user has the intended Role ID and inspect the relevant Component permissions. Similar display names do not make Role IDs equal. Role deletion never reassigns users; move every affected user explicitly before deleting a role. For advanced source, inspect references as described in Page source development.

Native elements have no permission editor

Native elements do not have a separate Permissions section. Use a Component that supports permission settings when you need consistent hidden or disabled behavior. Authorize sensitive operations again at the capability boundary that performs them.

Security boundaries

• Component role settings control display and interaction inside a Page. They are not mandatory authorization for equipment actions, Queries, Object methods, or file operations.
• Restrict access to workspaces, repositories, and delivery files. Do not share real App-user passwords in screenshots, documentation, or chat.
• Disable users promptly after departure or reassignment, and limit the number of App Admin users.
• After changing users, passwords, or roles, repeat acceptance on a real runtime Page with real roles.
• Page identity does not replace emergency stops, safety controllers, process interlocks, equipment protection, or backend business authorization.