How Permissions Are Named

Every tick box in a role stands for a short permission string such as event.editany or profile.viewfield.emails. Once you can read these strings, you can tell exactly what a role allows, why someone can or can't see something, and why Qik sometimes refuses to let a person hand out access. This article explains how the strings are built and how they combine.

If you're new to roles, start with Roles and Permissions and User Access Control.

The shape of a permission

A permission has two parts separated by a dot:

<what it applies to>.<what it allows>

• What it applies to is either a base type (such as profile, event, submission or workflowcard) or the key of one particular content type you've created (for example incidentReport).
• What it allows is an action, usually a verb followed by a qualifier: viewany, editown, listin and so on.

A role on its own does nothing. It takes effect when a person is given the role in a scope, either directly on their login, through an access pass, or through a position they hold in a group. The permission then applies to records in that scope and in every scope beneath it. See Scopes and Groups.

Record actions

These are the rows you see at the top of each content type in the role editor's Permissions tab.

A few types have extra actions of their own:

• Submit / Submit any (submit) on forms: submit that form, or any form.
• Collect (eticket.collect) on tickets: collect tickets from the ticket QR page without general access to ticket records.
• Define new … (define): create new content types based on that type.

Any, own and in

• any covers every record of that type in the scope.
• own covers records the person created, records they've been made an owner of, and records that list one of their profiles as an assignee (such as workflow cards assigned to them).
• in ("if participant") covers records that list one of the person's profiles as a participant, plus the messages posted on them. Today that means conversations, so these options only appear on conversations and messages.

"Own" and "in" are independent: a participant who isn't the author doesn't get "own" rights, and an owner who isn't a participant doesn't get "in" rights.

Stronger permissions include weaker ones

You don't need to tick every box. Qik treats these as included automatically:

• Edit includes view, and view includes list. Someone with editany can also view and list.
• Any includes own and in. Someone with viewany doesn't also need viewown or viewin.
• A base type includes all of its content types. submission.viewany covers the submissions of every form, while incidentReport.viewany covers only the submissions of that one form. In the role editor, a content type's tick box is greyed out when the base type already covers it. Messages are the one exception: a permission on plain messages doesn't extend to custom message types.

Some things are not included:

• Edit doesn't include delete, and delete doesn't include erase. Tick each one you want.
• Seeing a record doesn't mean seeing its contents. See the next section.

Field permissions: seeing what's inside a record

Record actions decide which records someone can reach. Field permissions decide which fields they can read or change on those records. You need both. A role with View any but no field permissions lets people see that records exist, but every field comes back blank, including the title. Empty rows in a list almost always mean a missing field permission.

Field permissions are set in the field table under each content type, which has View Any, View Owned, Edit Any and Edit Owned columns:

The field part works like this:

• * means all fields. profile.viewfield.* is the View All Fields row.
• Fields use their key path, for example emails, phoneNumbers, or data.uniform.shirtSize for a custom field.
• A parent path covers everything beneath it. viewfield.data.uniform includes data.uniform.shirtSize and every other field in that group.
• "Owned" field permissions follow the same meaning of own as above.

Edit field permissions don't grant reading. If people should see a field as well as change it, tick both View and Edit for it.

The View All, Edit All and Select if Owned buttons above each content type tick the matching record actions and the matching all-fields permissions together, which is usually what you want.

A worked example

Riverbank College wants front-desk staff to look up students' names and phone numbers but not their medical notes. Give them a role with:

• profile.listany and profile.viewany
• profile.viewfield.firstName, profile.viewfield.lastName and profile.viewfield.phoneNumbers

Grant the role in the scope that holds student profiles. Staff can now find and open students, but every other field, including any custom medical fields, stays hidden.

Grant only what you hold

Field permissions control who can edit a login's roles and access passes, but not what they can put there. To stop people giving away more than they have, Qik applies these rules whenever someone who isn't an administrator creates or edits a login or an access pass:

• You can only hand out access you already have. Each role you add, in each scope, must be one whose permissions you already hold in that scope, or hold through a permission that includes them (for example, a parent scope, an "any" permission that covers an "own" one, or a base type that covers a content type). The same applies to the roles and scopes inside an access pass you add.
• You can't add access to your own login. Only an administrator can change their own access passes or permissions.
• Only administrators can make someone an administrator.
• Removing access is never blocked. Anyone allowed to edit a login can take roles or access passes away.
• Access passes with invite codes: turning on, changing or rotating a pass's invite code requires you to be able to grant everything on the pass, because anyone with the code can join holding it.
• Changing who a login belongs to (its email address, username or password) is treated as granting all of that login's access afresh, so you must be able to grant all of it. Only administrators can change these details on an administrator's login.

When one of these rules stops a change, Qik explains why. For example, it names the role and scope involved and the permissions you're missing. Ask an administrator to make the change instead.

Access that doesn't come from permission strings

A few built-in rules give access without any role. Examples are being assigned a workflow card, being rostered onto an event, being in a conversation, and self-service profile editing. These are listed in Access Beyond Roles. Administrators have every permission in their own organisation.

FAQs