Users, roles, and runtime-page permissions

Theseus accounts belong to separate security boundaries. An app user signs in to a runtime page; it is not an editor login or a Runtime target administrator.

When to use this page

• You need to decide between an app user and a Runtime target user.
• A Page or widget should be visible only to a particular job role.
• The runtime page requests a login, or a signed-in user still cannot see a Page.
• You are reviewing default accounts before customer delivery.

The three account types

Account	Purpose	Management entry
Editor Qixin account	Qixin Code, online licensing, AI entitlement, and cloud services	Account menu in App Hub and System Settings
Runtime target account	Enter a target runtime; an Admin can deploy, debug, stop, and manage that target	System Settings → Runtime → User Management
App user	Sign in to one app's runtime pages and access Pages or widgets by role	App editor Settings → Users / Roles

These accounts do not grant one another access automatically. Connecting a Runtime target does not grant access to protected Pages in an app.

Where to go

• Roles and app users: Settings → Users / Roles.
• Page permission: open the Page, select its root properties, and set Permissions in Page Properties.
• Widget permission: select the widget and set Permissions in Properties.
• Runtime login: a protected Page requests login automatically, or use a currentUser widget to sign in, switch users, and sign out.

Configure roles and users

Design roles first

Roles should describe site responsibility rather than a person's name.

Role	Typical access
Operator	Runtime dashboard and basic operation
Supervisor	Parameter approval and batch management
Maintenance	Jog, diagnostics, and maintenance Pages
Admin	Every Page and widget

1. Under App Roles, select Add Role.
2. Enter a stable Role ID and a readable name.
3. Do not modify or delete the system Admin role.
4. Before saving, confirm that Role IDs are unique. Page and widget permissions reference the Role ID.

Create users second

1. Under App Users, select Add User.
2. Replace the default username and password.
3. Assign one role to the user.
4. Use Enabled to control whether the account can sign in.
5. Save, then test the account on the runtime page.

A new app includes the admin user, Admin role, and initial password 123456. Change it before first delivery. New users must not keep their initial password either.

Page and widget permissions

Page permissions

• Empty Permissions: anonymous visitors and all app users can open the Page.
• One or more roles: the user's role must match at least one entry.
• Admin users always have access.

A protected Page asks the visitor to sign in. After a successful login, the Page reloads with that user's permission context.

Widget permissions

• Empty Permissions: everyone who can open the Page sees the widget.
• Selected roles: only a matching role sees it.
• Admin users always see it.

The editor always shows every Page and widget for authoring. Verify permissions on the actual runtime page.

currentUser widget

currentUser displays the active app user and provides sign-in, user switching, and sign-out. It can use credential entry or show enabled users for selection; either mode still requires the correct password.

Recommended acceptance matrix

Scenario	Should see	Must not see
Signed out	Public dashboard and login entry	Protected Pages and widgets
Operator	Runtime and basic operation	Maintenance and administration
Maintenance	Diagnostics and maintenance Pages	Unauthorized administration
Admin	Every Page and widget	Nothing
Disabled user	Login failure	Any protected content

For every role, use at least one real test account to verify sign-in, direct URL access, Page navigation, sign-out, and sign-in again.

What success looks like

• Users see only Pages and widgets required for their jobs.
• A protected Page does not open when signed out or under the wrong role.
• currentUser displays, switches, and signs out the correct user.
• A disabled user cannot sign in, and an old password stops working after a change.
• Editor, Runtime target, and app-user boundaries are clear.

Common issues

Sign-in works, but the Page is still missing

Check that the user's Role ID matches the Page Permissions and that the user is Enabled. Similar display names do not make two Role IDs equal.

Deleting a role changed users to Admin

Deleting a role affects users that still reference it. Move those users to the intended role and inspect Page and widget references before deletion.

Permissions appear not to work in the editor

The editor displays everything for authoring. Test with the intended role on a runtime page.

Does hiding a widget make equipment operation safe?

No. Widget Permissions control runtime-page visibility. They do not replace device authorization, process interlocks, PLC logic, or hardware safety circuits.

How AI can help

AI can turn job responsibilities into a permission matrix and find invalid Role IDs or coverage gaps. For example:

Perform a read-only review of the current app's roles, users, Page permissions, and widget permissions. Produce a role-to-Page-to-restricted-widget matrix and identify excessive public access, unused roles, and default-password risk. Do not change accounts or passwords.

Never give real passwords to AI or let AI decide who should receive Admin.

What a person must confirm

• Every account maps to a real job, and departed or reassigned users are disabled.
• Initial passwords are changed and delivered through a secure channel.
• Admin count is controlled and the permission matrix is approved by the business owner.
• Device actions and Safety have independent protection beyond UI permissions.