Roles and Permissions

This article walks through setting up access in Qik: creating roles, combining them with scopes in access passes, and giving those passes to users. If you're new to the ideas behind it, read User Access Control first.

The building blocks

• Role: a list of permissions that says what someone can do, for example "view any article", "create profile" or "delete any event".
• Scope: an area of your data that says where they can do it, for example "Australia", "HR Department" or "Riverbank Campus".
• Access pass: pairs one or more roles with one or more scopes, and is then given to users. Think of it as a keycard.

The formula is: Access pass = Roles + Scopes → given to a user.

Where to find it

Open Access Control in the sidebar. The page has four areas:

• Active Users: links to your app users, Dashboard Users, Pending Invitations and Blocked / Banned Users, plus an Invite user button.
• Access Passes: create and edit access passes.
• Scopes: manage your scope areas.
• User Roles: create and edit roles and their permissions.

Step 1: Create a role

1. In Access Control, open User Roles and create a new role. Give it a clear name, such as "Event Coordinator" or "Report Viewer".
2. On the role's Permissions tab, each content type is listed with its permissions. Tick the ones this role should have.
3. Use the shortcut buttons on each content type to fill them in quickly: Select All, None, Create, View All, Edit All, Delete All and Select if Owned.
4. Further down, the Self Service section and the grouped account permissions cover things that aren't tied to a single content type.
5. Save the role.

Each permission is a specific action on a specific content type. Some examples:

• article.viewany: view any article
• profile.create: create a new profile
• event.editown: edit events you created
• event.deleteany: delete any event

For the full naming scheme, including field-level permissions such as hiding a single field, see How Permissions Are Named.

Common role patterns:

• Viewer: can view content but not create or edit it.
• Contributor: can create content and edit their own.
• Manager: can view, edit and delete any content of the types they manage.

A role on its own does nothing. It only takes effect once it's paired with a scope, either in an access pass, in a user's own permission sets, or on a group position.

Step 2: Set up your scopes

Scopes define where permissions apply. They form a tree, like folders, and permissions granted in a parent scope cascade down to every child scope:

• Organisation
  • Australia
    • Sydney
    • Melbourne
  • New Zealand
    • Auckland

A role granted in "Australia" also applies in "Sydney" and "Melbourne". A role granted at "Organisation" level applies everywhere. A role granted in "Sydney" does not apply in "Melbourne" or "Australia".

Every content record belongs to one or more scopes, and users only see content in scopes they have access to. See Scopes and Groups for more on building your scope tree.

Step 3: Create an access pass

1. In Access Control, open Access Passes and create a new access pass, for example "Sydney Event Coordinator".
2. Add a permission set. Each one pairs Roles (what) with Scopes (where).
3. Add more permission sets if the pass should grant different roles in different places. For example, the Event Coordinator role in Sydney plus a Viewer role at Organisation level.
4. Save the access pass.

When you change an access pass, everyone who holds it gets the new permissions. Access passes can also have an invite code, so people can join your organisation with the pass already attached.

Step 4: Give the access pass to users

Add access passes when you invite someone (the invite dialog has an Access Passes field), or edit an existing user later and add or remove passes. A user can hold any number of access passes, and the permissions are additive: they get the combined permissions of everything they hold.

You can also give one person extra permissions without making a new pass. Add a Permission Set (roles + scopes) directly on their user record. See Managing Users and Access Passes.

Example setup: a training college

1. Create roles: "Tutor" (create lessons, view students), "Head of Department" (view everything in their area) and "Registrar" (manage student records).
2. Create scopes: College → Business, Engineering, Design.
3. Create access passes: "Engineering Tutor" = Tutor role in Engineering, and "Registrar" = Registrar role in College.
4. Give "Engineering Tutor" to each Engineering tutor and "Registrar" to the registry staff.

Positions: permissions that come with a group role

Groups (scopes set to act as a group) have positions, such as "Team Leader" or "Coach". You can attach roles to a position, and everyone in that position gets those roles within that group. This keeps permissions in step with who is actually leading what. See Scopes and Groups to set it up.

Access that doesn't come from a role

Some access is granted by Qik's built-in rules rather than roles. Examples are seeing a workflow card you're assigned to, or a person editing their own details. These are covered in Access Beyond Roles and Self-Service Profile Editing.

Tips

• Build small, focused roles and combine them in access passes. This is easier to maintain than one large role per person.
• Name access passes after the job they represent ("Sydney Event Coordinator"), not after the people who hold them.
• You can only grant permissions that you hold yourself.
• To check what someone can actually see, use Impersonate on their login.

FAQs