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 and no default password.
• Each App user has exactly one role and can be enabled or disabled independently.
• When no App user is enabled, the App does not require App-user sign-in.
• 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.

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 user.
• 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.

Deleting a role elevates users that still reference it

When a non-system role is deleted in Settings, users that still belong to it are reassigned to Admin. Move those users to their intended roles first, then review every user before saving.

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 performs sign-in, switching, and sign-out in its own dialog. After a successful switch, the runtime Page reloads so its role checks use the new account immediately. Preview updates only its current preview session. Display text and role visibility can be configured for the Page; 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
No App user is enabled	The App does not require App-user sign-in
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. Preview 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.

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. After deleting a role, also confirm that affected users were not reassigned to Admin unexpectedly. 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.