User Access Control

Qik decides what each person can see and do by combining roles (what actions they can take) with scopes (which areas of your data those actions apply to). This article explains the ideas. For the step-by-step setup, see Roles and Permissions.

Key components

1. User (login): someone who can sign in, either to the Qik dashboard or to the apps and websites you build. A login is separate from the person's profile; see People, Users and Logins.
2. Content types: the kinds of record your organisation stores, such as profiles, events, articles or your own custom types.
3. Content records: the records themselves. Every record is created in at least one scope and can sit in several scopes at once.
4. Role: a list of actions a user may be able to perform, such as "create article" or "delete any event". Examples: "Website Viewer", "Manager", "Event Coordinator".
5. Scope: an area of your data. Scopes can be places ("Australia", "United States") or parts of your organisation ("HR", "Finance", "Customer Support"). They nest in a tree, like folders, and access granted in a parent scope flows down to its children.
6. Access pass: pairs roles with scopes and is given to users. The user gets those roles, but only inside those scopes.
7. Position: a named role within a group, such as "Team Leader" or "Coach". Roles attached to a position are granted to everyone in it, within that group.

How a user's permissions are worked out

When someone signs in, Qik combines everything that applies to them:

• the access passes on their login
• any individual permission sets added directly to their login
• roles from any group positions they hold
• for apps and websites, the permissions configured on the application they're using

All of these are additive. Holding more passes or positions only ever adds access.

Account administrators are the exception to all of this. They have full access to everything in the organisation and bypass access passes and scopes, so give that option out sparingly.

A few kinds of access come from Qik's built-in rules rather than roles. Examples are seeing a workflow card you're assigned to, or a person updating their own profile. See Access Beyond Roles and Self-Service Profile Editing.

How permissions are named

Each permission is a content type plus an action, such as event.viewany or profile.create. "Own" versions (editown) cover only records the user created; "any" versions (editany) cover every record in the scopes where the role is granted. Field-level permissions can hide or protect individual fields. The full scheme is in How Permissions Are Named.

Advantages of this approach

• Content can be split up and kept apart using scopes.
• When you change an access pass, everyone who holds it is updated at once. You don't need to edit people one by one.
• A user can hold several access passes at once. This lets you model real situations, such as someone who manages one branch but only views another.
• Group positions tie permissions to someone's actual job in a team. When they leave the position, the access goes with it.

Where to manage it

Everything lives under Access Control in the dashboard sidebar: users, Access Passes, Scopes and User Roles. Groups and their positions are managed under Groups.

Related reading: Managing Users and Access Passes, Scopes and Groups, Signing In and Account Security.