Roles and access

Every account in CardOffice has a role, which decides what it can do, and may have a scope, which decides whose records it can do it to. A faculty administrator, for example, can hold a role that manages people and photos, limited to the Faculty of Health.

Both are set by an administrator under Settings, Roles and access and on each person’s page under Settings, Users.

Built-in roles

Role	In short
Administrator	Everything in the organisation, including users, settings and the audit log.
Staff	People, photos and orders. No users, settings or reports.
Print operator	The print queue and printers, and reading the records they print.
Viewer	Reads people, orders and production. Changes nothing.

Custom roles

A custom role is a named set of permissions your organisation defines, such as Faculty administrator or Library desk. Create one under Settings, Roles and access, New role, and tick what it may do. Giving a person a custom role replaces their built-in role’s permissions with the custom role’s.

Three rules apply to every change, so the access model stays trustworthy:

• Nobody can grant more than they hold. An administrator cannot save a role, or give a person access, that includes a permission they do not have.
• Nobody changes their own access. Another administrator has to.
• Every change is in the audit log, recording what the access was and what it became.

Changing a role changes everyone who holds it, within a minute. Nobody is signed out by it. A role that someone holds cannot be deleted.

Limiting an account to some people

On a person’s page, under Access, Looks after, choose any combination of:

• Types of holder, such as students or staff,
• Departments, as they appear on people’s records,
• Campuses.

Values within one list mean any of them; the lists combine, so Nursing and Dunedin means Nursing people at Dunedin. Leave everything unticked for the whole organisation. Matching ignores capital letters and extra spaces.

A limited account sees and changes only those people, together with their photos, cards, door keys and invitations. The limit is enforced by the database itself, so it holds in every list, search, count, export and report, not only on the pages that were written with it in mind. The account cannot create a person outside its scope, or move someone out of it by changing their department; it is told why. Imports follow the same rule, row by row. Every page tells a limited account whose records it is looking at.

A limited account never holds permissions that cover the whole organisation, whatever its role says: users, settings, integrations, the audit log, reports, scheduled reports and invoices. An administrator of one faculty who could edit users could otherwise remove their own limit.

The who-can-do-what report

Settings, Roles and access, Who can do what lists every account with its role, the people it looks after, how it signs in (password or single sign-on, and whether it has a second factor), when it last signed in, and exactly what it can do. It is computed by the same rules that are enforced, so it cannot describe access the portal does not give.

Download signed report produces a ZIP with two CSV files, the account matrix and the role definitions, and a signature file for each. Each signature file holds the SHA-256 of its CSV, signed with the platform’s audit key, and can be checked the same way as an audit export.