Skip to main content

Account and permission boundaries

Theseus has three account domains. They protect cloud services, a runtime target, and an individual App runtime respectively. They do not replace one another.

Why this matters​

Many “I am signed in but still do not have permission” problems come from treating all three accounts as one identity. First decide whether the action belongs to the editor, the runtime target, or an App runtime page. That tells you which sign-in and administrator you need.

When you will encounter it​

  • signing in to Qixin for AI, source control, online licensing, or other cloud services;
  • connecting to a local or remote Runtime target for Run, Debug, Deploy, or Stop;
  • opening a runtime page as an operator and accessing role-restricted Pages or Widgets;
  • creating target accounts, App users, or site roles;
  • using the same username at different sign-in points and seeing different permissions.

The three account domains​

AccountScopePrimary purposeDoes not automatically grant
Editor Qixin accountThe desktop editor and Qixin cloud servicesAI entitlement, source control, online licensing, and other cloud capabilitiesRuntime target administration or App runtime roles
Runtime target accountOne RuntimeHost targetView and run deployed Apps; administrators deploy, debug, and manage the targetEditor cloud services or roles inside an App
App userThe runtime pages of one AppSign in to the App and access Pages and Widgets according to rolesApp editing, deployment, or Runtime target management

Editor Qixin account​

Local App Hub, editor, and authoring work do not require a Qixin sign-in. Qixin sign-in is for cloud services that require account entitlement. It does not automatically create a Runtime target account or make you an operator inside an App.

If a Runtime target administrator has linked your Qixin identity to a target account, the desktop can reuse that authorization when connecting to the target. The permissions are still separate; linking only removes an extra password prompt.

Runtime target account​

Each Runtime target has its own accounts and sessions. After switching targets, use the connection state of the new target.

Target roleCapabilities
UserSign in to the runtime-only UI, view deployed Apps, open runtime pages, and run an already deployed App
AdminIncludes User capabilities and can deploy, Debug, Materialize, Stop, write a License, change runtime settings, and manage target accounts

Run from the desktop normally prepares and deploys the current runtime package first, so starting a new desktop version on a target requires Admin access. User access is designed for starting an App that is already deployed from the runtime-only UI.

App user​

App users and roles belong to one App. They are used to:

  • restrict which Pages a person can open;
  • control which Widgets are visible to a role on a runtime page;
  • switch operator identity on a shared terminal.

An App user cannot enter the editor and cannot deploy, stop, or administer a Runtime target. The Admin role inside an App and the Admin role on a target share a name but have completely different scopes.

Permissions are not safety interlocks

Page and Widget roles are runtime-page access controls. They do not replace emergency stops, safety relays, safety controllers, equipment protection, or server-side operation authorization.

Questions to ask when access is denied​

  1. Am I using a cloud service, operating a Runtime target, or opening an App runtime page?
  2. Which Runtime target is selected in the Navbar?
  3. Is the active target session a User or Admin session?
  4. Which App user is signed in on the runtime page, and which roles does it have?
  5. Does this operation intentionally require a higher permission or explicit approval?

Common misconceptions​

  • Signing in to Qixin is not the same as signing in to a Runtime target. Cloud authorization does not automatically become machine-runtime permission.
  • Target Admin is not App Admin. The former manages a runtime target; the latter is only a role within one App.
  • An App user cannot deploy or Stop an App. It only controls access inside the App runtime.
  • Matching usernames do not imply the same identity. The three account domains can each contain a user with the same name.
  • A session on one Runtime target does not connect you to another target. Every target keeps its own accounts and state.
  • Hiding a button does not make a machine safe. Critical actions still need equipment, runtime, and engineering safeguards.

Next step​