Roles, Permissions & Levels

Controlling user access and capabilities is fundamental to managing any online community. UNA CMS provides a powerful and granular system for this, primarily through the Permissions app (Studio > Permissions) and the Roles app (Studio > Roles). It's essential for Operators to understand the distinction between these two systems:

• Permissions & Membership Levels: Govern what frontend users (community members, including frontend administrators and moderators) can see and do on the live website. This system defines user groups (Levels) and assigns specific capabilities (Actions) to them.
• Roles: Specifically control Operator access within UNA Studio. They define which parts of the backend configuration interface different Operator accounts can use.

This guide provides Operators with a comprehensive understanding of how to configure Membership Levels, Actions (Permissions), and Operator Roles within Studio to effectively manage access across the entire platform.

The Permissions App: Controlling Frontend User Access (ACL)

The Permissions app (Studio > Permissions) is the central hub for defining the Access Control List (ACL) for your frontend users. The ACL determines precisely who can perform which actions on the site. It operates based on two main components: Membership Levels and Actions.

Membership Levels (Studio > Permissions > Levels)

Membership Levels are categories or groups you define to classify different types of users on your site based on their access needs or status. Each user's Profile is assigned to one Membership Level, which dictates their permissions.

• Purpose: To group users for applying permissions collectively (e.g., all "Standard" members have the same base permissions, while "Moderators" have additional ones).
• Standard Levels: UNA typically comes with several pre-defined levels:
  • Unauthenticated: Users who are not logged in (guests).
  • Account: Users who are logged in but may not have created a specific community profile yet (relevant in multi-profile setups).
  • Standard: The default level for regular registered members.
  • Unconfirmed: Users whose accounts are pending confirmation (e.g., email verification).
  • Pending: Accounts awaiting administrative approval (if configured).
  • Suspended: Accounts manually suspended by an Operator.
  • Moderator: Users granted specific content moderation privileges.
  • Administrator: Users granted broad frontend community and content management privileges (distinct from Operators).
  • Premium/Paid Levels: Additional levels often linked to subscriptions or specific privileges (e.g., "Premium," "Agency," "Hobby" in the screenshot example).
• Creating/Editing Levels:
  • Click Add New Level to create custom membership tiers.
  • Click the pencil icon (✏️) next to an existing level to edit its properties.
  • Configuration Options (per Level):
    • Enable Toggle: Activate or deactivate the level.
    • Icon: Assign a visual icon to the level.
    • Title: The name of the Membership Level (e.g., "Premium Member," "Content Creator").
    • Actions Count: Shows how many specific Actions are currently allowed for this level (configured on the next tab).
    • Storage: Define a total storage space limit (in MB/GB, ∞ for unlimited) for users at this level.
    • Max File Size: Set the maximum size (in MB) for a single file upload for users at this level (∞ for unlimited).
    • Max Files: Limit the total number of files a user at this level can upload (∞ for unlimited).
    • (Other potential fields): May include options for pricing, duration (for paid levels), password expiration rules, etc.

Actions (Studio > Permissions > Actions)

Actions represent specific, granular capabilities or permissions within the UNA system. Modules define the actions related to their functionality.

• Purpose: To represent individual tasks a user might perform (e.g., "Post Comment," "View Profile," "Delete Own Video," "Edit Any Group").
• Granularity: Actions are highly specific, allowing for fine-tuned control.
• Module-Defined: Each UNA app (module) typically registers the actions relevant to its features (e.g., the "Posts" module defines actions like "Create Post," "Edit Own Post," "Delete Any Post"). The Module column shows which app defined the action.
• Enabling/Disabling Actions Globally: The Enable toggle on this Actions tab acts as a master switch for the action across all Membership Levels. If an action is disabled here, no one can perform it, regardless of their level settings. It's generally recommended to leave most standard actions enabled here and control access via the Levels matrix.
• Advanced Action Settings (Gear Icon ⚙️): Clicking the gear icon next to an action allows setting advanced constraints:
  • Number of allowed actions: Limit how many times a user can perform this action within a specific period (e.g., limit to 5 posts per day). Leave blank for unlimited.
  • Number of actions is reset every: The time period (in hours) after which the action counter resets. Leave blank if the counter should not reset automatically based on time.
  • This action is available since / This action is available until: Define a specific date/time window during which the action is permitted (e.g., for promotional features). Leave blank if always available (or always unavailable outside the window).

Configuring Permissions: The Levels & Actions Matrix

The core of permission management happens by linking Levels to Actions. This defines which Membership Levels are allowed to perform which Actions.

1. Select a Level: Go to the Levels tab and click on the name or action count link for the Membership Level you want to configure (e.g., click on "Moderator").
2. View Actions: You'll be taken to the Actions tab, now filtered to show permissions specifically for the selected Level (e.g., "Moderator").
3. Filter by Module (Optional): Use the "All Modules" dropdown to filter actions related to a specific module (e.g., show only "Posts" actions for the Moderator level).
4. Grant/Revoke Permissions: Use the Enable toggle next to each action to allow (Green/ON) or disallow (Grey/OFF) that specific capability for the currently selected Membership Level.
5. Save Changes: While changes often save automatically when toggling, ensure all desired permissions are set. There isn't typically a separate "Save" button on this matrix view itself.

Example: To allow Moderators to delete any post:

1. Select the "Moderator" Level on the Levels tab.
2. On the Actions tab (now showing Moderator permissions), filter by the "Timeline" or "Posts" module.
3. Find the action named something like "Posts Delete Any" or "Timeline Delete Any Post".
4. Ensure the Enable toggle next to it is ON (Green).

The Roles App: Controlling Operator Access to Studio

The Roles app (Studio > Roles) operates entirely separately from the Permissions app and Membership Levels. Its sole purpose is to manage access levels within UNA Studio for users designated as Operators.

Operator Roles (Studio > Roles > Levels)

Operator Roles define different levels of access to Studio functionalities.

• Purpose: To allow the main site owner (Master Operator) to delegate specific Studio management tasks to other team members without granting them full, unrestricted access to everything.
• Standard Roles:
  • Master: Has unrestricted access to all parts of UNA Studio. Cannot be deleted or overly restricted. Typically the first Operator account created.
  • Operator: A default role that usually grants access to most, but potentially not all, Studio functions compared to Master. Its specific permissions can be edited.
• Creating Custom Roles:
  • Click Add New Role.
  • Give the role a descriptive Title (e.g., "Designer," "App Manager," "Content Structure Admin").
  • Optionally add a Description.
• Assigning Operator Roles:
  • Go to Studio > Accounts.
  • Find the user's Account record.
  • Click the gear icon (⚙️).
  • Select Set Operator Role.
  • Choose the desired Operator Role from the dropdown list.
  • Click Save. (Note: You must first mark the account as an 'Operator' in the main account edit screen if not already done).

Role Actions (Studio > Roles > Actions)

This tab defines what each Operator Role can do within Studio. The "Actions" here correspond to broad categories of Studio apps or functions.

• Available Actions (Examples):
  • Manage Roles: Ability to use the Roles app itself.
  • Manage Apps: Ability to use the App Store (install/uninstall/update apps).
  • Use 'Appearance' apps: Access to Designer, Template settings, etc.
  • Use 'Structure' apps: Access to Pages, Navigation, Forms builders.
  • Use 'Content' apps: Access to manage settings of content modules (Note: distinct from moderating content itself).
  • Use 'Users' apps: Access to Accounts, Permissions, Badges, etc.
  • Use 'Configuration' apps: Access to Settings, Polyglot, Storage, etc.
  • Use 'Extensions' apps: Access to specific extension module settings.
  • Use 'Integrations' apps: Access to integration module settings.
• Configuring Role Permissions:
  1. Select the Operator Role you want to configure (e.g., "Designer") from the dropdown at the top.
  2. Use the Enable toggle next to each action category to grant or deny access to that part of Studio for the selected Operator Role.
  3. Click Save.

Key Differences: Operator Roles vs. Membership Levels

Best Practices

• Least Privilege: Apply this principle to both systems. Don't grant Moderator level unnecessary admin actions; don't give Operators access to Studio sections they don't need via Roles.
• Clear Naming: Use descriptive names for custom Membership Levels and Operator Roles.
• Test Permissions: After configuring levels or roles, log in as a test user assigned to that level/role to verify they have the correct access and restrictions.
• Regular Audits: Periodically review Membership Level permissions and Operator Role assignments.
• Document: Keep internal notes on why specific permissions are granted to certain levels or roles.

Conclusion

UNA's dual system of Membership Levels/Permissions (for frontend users) and Operator Roles (for Studio access) provides robust and granular control over platform access. The Permissions app is where Operators define what community members can do on the live site by assigning Actions to Membership Levels. The Roles app is where Operators define which parts of the backend configuration interface other Operators can access. Mastering both systems in Studio is essential for building a secure, well-structured, and effectively managed UNA community.