Skip to content

Users, roles, modules and branding

Location: Admin → Access Control → Users. Viewing requires auth:view; editing requires auth:manage.

User guide

User guide: Users, roles, modules and branding

Manage accounts, permissions, services and branding. Configure menu access, runtime writes and API authorization separately.

Access Control: manage users

Location: Admin → Access Control → Users. Viewing requires auth:view; editing requires auth:manage.

  1. Create a user with username, display name, initial password, language and status.
  2. Assign roles and, when appropriate, require a password change at the next sign-in.
  3. Edit roles and state; a blank password preserves the existing one. After saving, check page and action access with that account.
  4. Disable an account to stop further access. Review the account and confirmation prompt before deleting it.

Access Control: roles and permissions

Roles grant selected permissions regardless of their names.

  1. Open Roles and create a role with code, name, description and enabled state.
  2. Find permissions by group, read their descriptions, select the required items and save.
  3. Assign the role in Users. Verify viewing, editing, writes, alarm acknowledgement and exports separately.
  4. Built-in roles cannot be deleted; the super-admin role remains enabled. If an entry is missing, check user status, enabled roles and the required permission.

Runtime menus and sign-in requirements

A menu’s login requirement controls access to that page. RUNTIME_PUBLIC_READ controls the deployment’s runtime read policy.

  1. Select the menu in Menus, set Login required, and save. The runtime entry uses its saved name, order and target page.
  2. When public reads are enabled, runtime values, alarms and trends can be read within their scope. Disabling public reads requires a valid login.
  3. Writes still check the user’s write permissions, the Tag’s runtime-write setting and the page’s declared capabilities.
  4. IO State API Profiles and Access Keys are managed independently of menu login requirements.

Modules: status and runtime control

Location: Admin → Modules. Viewing requires site:view; management requires site:manage.

  1. Search by name, code or description, or filter by running, attention, disabled or offline state.
  2. Select a module and inspect its status and available controls. Start, stop or restart only where those controls are available.
  3. Stopping or restarting IO, Alarm, Trend or Script pauses intake and drains tasks. Review the impact, submit, then check the receipt, health and readiness. For unknown results, use Verify Original Request instead of resubmitting. View services without controls in System Status.
  4. Use Devices for PLC connection and collection details. A running module does not prove a PLC is connected.

Branding: title and logos

Location: Admin → Branding. Requires branding:manage.

  1. Set the runtime title and upload the left and right logos. PNG, JPG and WebP are supported, up to 2 MB per file.
  2. Check image proportions and text in the preview. Clearing a logo or restoring defaults changes the form first.
  3. Save to apply, then open the runtime page to inspect the title and logos.
Mingcedar Access Control page showing users, roles, and permissions
Figure 1: Access Control

The role editor contains role details, built-in permissions and explanations of each permission. Review the intended grants before saving.

Mingcedar Branding page
Figure 2: Branding

Branding shows the runtime title, left and right logo selectors, and the header preview.

Mingcedar Modules page
Figure 3: Modules

The module list shows service status; the selected module shows local execution, access, and enabled status.

Click the image again or press Esc to close