Skip to main content
Version: Next

Managing Permissions

What is the Permissions System?​

The Permissions system in AI SCADA provides role-based access control (RBAC) for your SCADA applications. It allows you to manage user access to views, components, and operations based on assigned roles.

The system uses a pre-built runtime component that requires minimal configuration—simply add it to a view and start managing users and roles.

When to Use Permissions?​

The Permissions system is essential for:

  • Multi-User Environments: Control what different operators can see and do
  • Security Compliance: Meet regulatory requirements for access control
  • Operational Safety: Prevent unauthorized access to critical operations
  • Audit Requirements: Track who has access to what functionality
  • Role Separation: Distinguish between operators, supervisors, engineers, and administrators

Permission Levels​

The system provides three levels of access control:

1. View Access​

Control which views users can access.

Behavior:

  • Checked views: User can navigate to and view
  • Unchecked views: Hidden from navigation, cannot access

Use Cases:

  • Hide engineering views from operators
  • Restrict maintenance views to maintenance personnel
  • Show management dashboards only to supervisors

2. Component Operations​

Control which components users can interact with.

Behavior:

  • Checked components: User can interact (click, input, etc.)
  • Unchecked components: Visible but disabled, events do not trigger

Use Cases:

  • Disable start/stop buttons for operators
  • Prevent parameter changes by unauthorized users
  • Restrict recipe modifications to engineers

💡 Tip: Component-level permissions require enabling "Permission Control" in the component's properties during development.

3. Runtime Module Operations​

Control which operations users can perform in runtime modules.

Behavior:

  • Checked operations: User can perform action
  • Unchecked operations: Button/action is disabled

Use Cases:

  • Restrict user creation to administrators
  • Prevent role deletion by supervisors
  • Control data export permissions

Adding the Permissions Component​

Step 1: Create a Permissions View​

  1. Create a new view in the View Editor
  2. Name it "Permissions Management" or similar
  3. Navigate to Components > Runtime > Permissions Management
  4. Drag the component to the canvas
  5. Resize to fill the view
  6. Save the view

📷 [Screenshot: Permissions Management component in View Editor]

Step 2: Add to Navigation​

  1. Add the view to your main menu or navigation
  2. Restrict access to administrators only (configure after creating admin role)
  3. Save changes

Step 3: Run the Application​

  1. Click Run to start the runtime
  2. Navigate to the Permissions Management view
  3. The component is ready to use

📷 [Screenshot: Permissions Management interface in runtime]

Managing Roles​

Roles define sets of permissions that can be assigned to users.

Create a Role​

  1. Open the Permissions Management view
  2. Click the Roles tab
  3. Click Add button (top right)
  4. Enter role information:
    • Role Name: Descriptive name (e.g., "Operator", "Supervisor", "Engineer")
    • Description: Optional description of role purpose
  5. Click Confirm

📷 [Screenshot: Add Role dialog]

Example Roles:

RoleDescriptionTypical Permissions
AdministratorFull system accessAll views, all operations
EngineerConfiguration and troubleshootingMost views, parameter changes, recipe management
SupervisorProduction oversightProduction views, reports, limited control
OperatorDay-to-day operationProduction views, basic controls, no configuration
ViewerRead-only accessView-only, no controls

Configure Role Permissions​

  1. Locate the role in the list
  2. Click Permission Settings button
  3. Configure permissions:

View Permissions:

  • Check views the role can access
  • Uncheck views to hide from role
  • Supports hierarchical menus (parent and child views)

Component Permissions:

  • Expand each view to see components
  • Check components the role can interact with
  • Unchecked components are disabled for this role

Operation Permissions:

  • Check operations the role can perform
  • Applies to runtime module buttons and actions

📷 [Screenshot: Permission Settings dialog showing view and component permissions]

  1. Click Confirm to save permissions

💡 Tip: Start with minimal permissions and add as needed. It's safer to grant permissions incrementally than to remove them later.

Edit a Role​

  1. Locate the role in the list
  2. Click Edit button
  3. Modify role name or description
  4. Click Confirm

⚠️ Caution: Editing a role affects all users assigned to that role.

Delete a Role​

  1. Locate the role in the list
  2. Click Delete button
  3. Confirm deletion

⚠️ Caution: Cannot delete a role that has users assigned to it. Reassign users first.

Managing Users​

Users are individuals who log in to the system. Each user is assigned one or more roles.

Create a User​

  1. Open the Permissions Management view
  2. Click the Users tab
  3. Click Add button (top right)
  4. Enter user information:
    • Name: User's full name
    • Username: Login username (unique)
    • Password: Login password
    • Roles: Select one or more roles to assign
  5. Click Confirm

📷 [Screenshot: Add User dialog]

Password Requirements:

  • Minimum length (configurable in system settings)
  • May require complexity (uppercase, lowercase, numbers, symbols)
  • Users can change their own password after login

Role Assignment:

  • Users can have multiple roles
  • Permissions are cumulative (user gets all permissions from all assigned roles)
  • At least one role must be assigned

View User Permissions​

  1. Locate the user in the list
  2. Click View Permissions button
  3. Review the user's effective permissions:
    • All views the user can access
    • All components the user can interact with
    • All operations the user can perform

📷 [Screenshot: User Permissions view showing combined permissions from multiple roles]

💡 Tip: Use this feature to verify users have correct access before deployment.

Edit a User​

  1. Locate the user in the list
  2. Click Edit button
  3. Modify user information:
    • Name
    • Username
    • Password (optional, leave blank to keep current)
    • Roles
  4. Click Confirm

Delete a User​

  1. Locate the user in the list
  2. Click Delete button
  3. Confirm deletion

⚠️ Caution: Deleting a user is permanent and cannot be undone. Consider disabling the user instead if you may need to restore access later.

Import/Export Users​

Export Users:

  1. Click Export button (top right)
  2. Select export location
  3. System exports user list to Excel file

Excel File Structure:

NameUsernamePasswordRoles
John Doejdoe********Operator, Supervisor
Jane Smithjsmith********Engineer

Import Users:

  1. Click Import button (top right)
  2. Select Excel file to import
  3. System processes import:
    • New users are created
    • Existing users are updated (based on username)
  4. Review import results

💡 Tip: Use import/export for bulk user management or to replicate user setup across multiple systems.

Enabling Component-Level Permissions​

To control individual components with permissions, you must enable permission control during development.

Enable Permission Control for a Component​

  1. Open the view in the View Editor
  2. Select the component
  3. In the Properties panel, find Permission Control
  4. Check Enable Permission Control
  5. Save the view

📷 [Screenshot: Component properties showing Permission Control checkbox]

Supported Components:

  • Buttons
  • Input controls (text box, dropdown, etc.)
  • Read/Write components
  • Custom components with events

Behavior:

  • When enabled, component appears in role permission settings
  • Administrators can control whether role can interact with component
  • Disabled components are visible but non-interactive

💡 Tip: Enable permission control only for components that require access restrictions. Too many controlled components can make permission management complex.

Common Permission Scenarios​

Scenario 1: Operator vs. Supervisor​

Operator Role:

  • Access: Production views, basic monitoring
  • Controls: Start/Stop production (with confirmation)
  • Restrictions: Cannot change parameters, cannot access engineering views

Supervisor Role:

  • Access: All production views, reports, analytics
  • Controls: All operator controls plus parameter adjustments
  • Restrictions: Cannot access system configuration

Implementation:

  1. Create "Operator" role with basic permissions
  2. Create "Supervisor" role with extended permissions
  3. Enable permission control on parameter input components
  4. Grant Supervisor role access to parameter components

Scenario 2: Read-Only Access​

Viewer Role:

  • Access: All views
  • Controls: None (all buttons disabled)
  • Use Case: Management, visitors, remote monitoring

Implementation:

  1. Create "Viewer" role
  2. Grant access to all views
  3. Do not grant any component operation permissions
  4. Users can see everything but cannot interact

Scenario 3: Maintenance Personnel​

Maintenance Role:

  • Access: Equipment views, maintenance views, alarm history
  • Controls: Maintenance mode, equipment reset, alarm acknowledgment
  • Restrictions: Cannot start/stop production, cannot change recipes

Implementation:

  1. Create "Maintenance" role
  2. Grant access to maintenance-related views
  3. Enable permission control on maintenance buttons
  4. Grant Maintenance role access to maintenance operations only

Scenario 4: Multi-Role User​

Production Manager:

  • Roles: Supervisor + Engineer
  • Effective Permissions: Combined permissions from both roles
  • Use Case: User needs both production oversight and engineering capabilities

Implementation:

  1. Create user account
  2. Assign both "Supervisor" and "Engineer" roles
  3. User automatically gets all permissions from both roles

Best Practices​

Role Design​

Keep Roles Simple:

  • Define clear, distinct roles
  • Avoid too many roles (5-10 is typical)
  • Use descriptive role names

Follow Principle of Least Privilege:

  • Grant minimum permissions needed for job function
  • Start restrictive, add permissions as needed
  • Regularly review and audit permissions

Document Roles:

  • Maintain documentation of each role's purpose
  • List typical job functions for each role
  • Document permission rationale

User Management​

Username Standards:

  • Use consistent naming convention (e.g., first initial + last name)
  • Avoid special characters
  • Keep usernames short and memorable

Password Policy:

  • Enforce strong passwords
  • Require regular password changes
  • Do not share passwords between users

Account Lifecycle:

  • Create accounts only when needed
  • Disable accounts when users leave
  • Review active accounts periodically

Security​

Protect Administrator Access:

  • Limit number of administrator accounts
  • Use strong passwords for admin accounts
  • Monitor administrator activity

Audit Access:

  • Review user permissions regularly
  • Check for unused accounts
  • Verify role assignments are current

Test Permissions:

  • Test each role before deployment
  • Verify users cannot access restricted areas
  • Confirm disabled components are truly disabled

Troubleshooting​

User Cannot Log In​

Problem: User enters correct credentials but cannot log in.

Possible Causes:

  1. Account is disabled
  2. Password is incorrect
  3. Username is case-sensitive

Solutions:

  1. Verify account is active in user list
  2. Reset password for user
  3. Check username spelling and case
  4. Review system logs for login errors

User Cannot Access View​

Problem: User is logged in but cannot see expected views.

Possible Causes:

  1. View not granted to user's role
  2. User has wrong role assigned
  3. View is hidden in navigation

Solutions:

  1. Check role permissions for the view
  2. Verify user has correct role assigned
  3. Review view permissions settings
  4. Check navigation menu configuration

Component Not Disabled for Role​

Problem: Component should be disabled but user can still interact with it.

Possible Causes:

  1. Permission control not enabled for component
  2. Role has permission to component
  3. User has multiple roles with conflicting permissions

Solutions:

  1. Enable permission control in component properties
  2. Check role permission settings for component
  3. Review all roles assigned to user
  4. Test with single-role user to isolate issue

Permissions Not Taking Effect​

Problem: Permission changes don't apply immediately.

Possible Causes:

  1. User needs to log out and log back in
  2. Changes not saved
  3. Cache issue

Solutions:

  1. Have user log out and log back in
  2. Verify changes were saved in permission settings
  3. Restart runtime application
  4. Clear browser cache (if using web client)

Cannot Delete Role​

Problem: Delete button is disabled or deletion fails.

Possible Causes:

  1. Role has users assigned to it
  2. Role is system default role

Solutions:

  1. Reassign users to different role first
  2. Check if role is marked as system role (cannot delete)
  3. Verify you have administrator permissions

Next Steps​

Now that you know how to manage permissions, explore:

Last updated on