Docs › Administer

People, roles and access

Add people, grant roles, look through somebody else's eyes.

This page shows you how to add people, let them sign in, and decide what each of them may do. It also covers looking at the repository through somebody else's eyes, which is how you check that access is set up the way you meant.

Before you start

• Everything here is on Administration → People and Persona.
• To change anything on that screen you need Manage users and roles (ACCESS_MANAGE). In the starter model only Sysadmin has it. Without it, the screen is read-only and says so.

The screen has a tab for each part of the access model, from People to History. Most values can be clicked and changed in place, and each save is recorded on the History tab.

Add a person and invite them

A person you add cannot sign in until they have set a password. You never set or see it: KRISID gives you a one-time link and they choose their own.

1. Open the People tab and press Add a person.
2. Fill in Username, Name and Email. The username is what they sign in with. It can't be changed later, so use something like r.iyer rather than a full name.
3. Press Add them.
4. In the person's row, under Signing in, press Invite, then Make it.
5. Send the link. Copy puts it on your clipboard. If a mail server is set up, Send it emails it from KRISID. If not, Email it opens your own mail program with the message already written.

The link works once and lasts 72 hours. It is shown only this once, so send it before you leave the screen. When they have used it, the row says has a password.

A new person starts with Viewer, so they can read the repository as soon as they sign in. Give them more on the Assignments tab (see below).

If somebody forgets their password, press Send a new link in their row. Their old password stops working and they are signed out everywhere.

The Time zone column shows the zone that person's browser last reported — Asia/Kolkata, Europe/London. It is read-only: nobody types it, and it changes by itself when they next sign in from somewhere else. KRISID uses it to write deadlines in an email the way the person reading it would read them on screen. See Change requests.

Tip: People can also create their own accounts if you allow it. See Sign-up and the mail server.

Roles and what they allow

A role is a named set of permissions. The Permissions tab is a grid with one row per permission and one column per role, in five groups — Assets, Model, Access, Workflow, Views. Click a tick to grant or take away that permission.

How far a tick reaches depends on the permission, and each one says which it is — in small italics beside its name on the grid, with the whole sentence on hover:

The role's dropdown entry on Assignments says which kind of role it is, and the three reaches above are a property of the permission, not of the role.

What reading needs

Somebody with no role at all now sees nothing. Until v91 four of these permissions were on the grid and nothing asked for them: an account with no roles could read every asset, its history, the metamodel and the workflows. They are asked for now — View assets, View history, View the metamodel and View workflows — and a person holding none of them is refused, by name, with the roles that carry it.

Reading is all or nothing. KRISID does not hide one asset from one person: a catalogue exists to be searched, and a list that quietly left rows out would be a worse answer than a refusal. So those four count anywhere — a Consumer held over a single data domain reads the whole catalogue — and withholding one is how somebody is made write-only, deliberately, in the access workbook.

Nothing changed under anybody when you upgraded. Every active role that held any permission at all was given the four, so everybody reading the estate the day before read it the day after. What changed is that you can now take them away.

What stays open to anybody signed in: who exists, what the roles are and who holds them (which is how somebody finds who to ask — usernames and email addresses still need See usernames and email addresses), the list of sources, and where this repository can call out to. The access workbook is not a screen: downloading it needs View users and roles as well as See usernames and email addresses.

The starter roles are Sysadmin, Metadata Manager, Viewer and Workflow Developer, which apply to the whole repository, and Data Owner, Data Steward, Technical Custodian, Subject Matter Expert and Consumer, which apply to single assets. Your repository may have renamed or changed them.

Whole-repository roles and per-asset roles

Each role has a Held over setting:

• the whole repository: the role applies everywhere. Sysadmin and Viewer work like this.
• one asset: the role applies to one asset and to everything under it. Data Owner and Data Steward work like this. For example, a steward of a data domain looks after everything the domain owns.

For a per-asset role, May be assigned at can limit which kinds of asset it may be held over. The Inheritance tab controls how far a per-asset role passes down.

To give somebody a role:

1. Open the Assignments tab and press Assign a role.
2. Choose the role, whether it is held by a person or a team, and who.
3. For a per-asset role, choose the kind of asset and then the asset.
4. Press Assign it.

You can also make somebody responsible from an asset's own page. See Owners, stewards and responsibilities.

To add a role of your own, press Add a role on the Roles tab, then tick its permissions on the grid.

Teams

A team lets you assign a role once, to a group, instead of to each person. On the Teams tab, press Add a team, give it a name, then open it and use Add somebody to add members. A team with nobody in it can still hold responsibilities, so the responsibility isn't lost when people move on.

Who can see usernames and email addresses

Most of this screen is open to anybody who can sign in: who exists, what the teams and roles are, and who holds what. That is deliberate — it is how somebody finds out who to ask about a table.

Two things on it are not. See usernames and email addresses (PERSON_IDENTIFY) is what shows you other people's Username and Email, and it is also what lets you download the access workbook. In the starter model only Sysadmin has it, and it is one tick on the Permissions tab like any other.

Without it:

• the Username and Email columns are not on the People tab at all, and a line under the tabs says so. The rest of each row — name, teams, what they are accountable for, time zone, active — is there as before.
• a person's own page shows hidden where their email address would be.
• Download the current access model is replaced by the reason. The workbook is keyed on usernames, so there is no sensible copy of it with them taken out: uploading one would read as "create everybody again, and drop every assignment held by a person". You can still apply a workbook somebody else downloaded, if you hold ACCESS_MANAGE.
• Invite is not offered, because an invite is made by username. Whoever holds ACCESS_MANAGE normally holds this too — when KRISID upgraded your repository it gave PERSON_IDENTIFY to every role that already had ACCESS_MANAGE, so nobody who was administering people stopped being able to.

Your own username and email address are always yours to see, on your profile and on your own person page, whether you hold the permission or not. You sign in with your username.

Two things this does not do, said plainly so you can decide whether you need more:

• Usernames still appear elsewhere. They are in the person picker, in Viewing as, beside an approval, and in the activity log — a log that said "somebody changed this" would not be a log. If a username is itself sensitive in your organisation, this permission is not enough on its own; tell us and we will say what closing that would cost.
• Email addresses are closed everywhere else already, but not on the Logs screen, where the mail log lists what was sent and to whom. That needs Read the logs (LOG_VIEW), which is Sysadmin's by default.

Note: a role carrying PERSON_IDENTIFY cannot be the role sign-up hands out. An open form that gave strangers the right to read every address would be a mailing list with extra steps. See Sign-up and the mail server.

Switch somebody off, or remove them

When somebody leaves, click Active in their row and choose No. They are signed out at once and can no longer sign in. Their name stays on everything they did.

The × at the end of a row removes a person completely. KRISID refuses to remove somebody who still holds an assignment. Hand their responsibilities to someone else first, or switch them off instead. Roles work the same way: a role somebody holds can't be removed, but you can set it to inactive, and an inactive role grants nothing. You can't switch off or remove your own account.

View the repository as somebody else

When somebody says "I can't see it", you can look at the repository exactly as they see it.

1. In the top-right corner, press your name.
2. Choose View as somebody else.
3. Type part of the person's name, and press their name in the list.

A banner across the top says who you really are and whose view you are seeing. Press Back to myself in the banner, or in the same menu, to go back to your own.

The rules:

• You need View as somebody else (VIEW_AS). In the starter model only Sysadmin has it.
• It is read-only. Nothing can be changed while you are viewing as somebody else, and History always records you as yourself.
• You can only view as active people.
• On the People and Persona screen, Viewing as has a button that switches this off for the whole repository. While it is off, only people who also hold ACCESS_MANAGE can use it, so the person who can switch it back on is never locked out.

Workflow controls

On the screen, an edit to an asset a workflow governs is always proposed. The Workflow controls tab decides what happens when the same change arrives another way. Changing them needs Manage users and roles, and each change is written to the System log.

• A direct write through the API: is written, as before (the default); becomes a change request (the API answers 202 with the request's id); or is refused (409, saying how to propose it instead).
• A workbook load: writes, as before (the default); holds governed changes as change requests; or leaves governed rows out, and says which. Anybody holding Load past workflows loads directly whatever this says.

Maintenance page

Maintenance is a tab on this screen, for whoever holds Manage users and roles (ACCESS_MANAGE) — Sysadmin in the starter model.

Tick Show the maintenance page and, from that moment:

• Everybody who cannot switch it is signed out where they stand, so nobody is halfway through an edit while the work happens.
• They see one page instead of the repository, wherever they go: signing in, signing up, or opening an address they had bookmarked. Nothing of the repository is drawn behind it, and every request is refused rather than half-answered.
• You keep working as normal, and switch it off when you are done.

What the page shows:

The page wears your own logo or word mark, and has nothing on it but Try again.

Switching it on or off is written to the System tab of the activity log, with who did it and how many sessions were ended.

Good to know

• To load or change many people at once, use the workbook on the same screen: Download the current access model, edit it, then upload it. You see what would change before anything is written. Usernames, team codes and role codes are the keys, so changing one creates a new row. It doesn't rename the old one. Downloading it needs See usernames and email addresses (PERSON_IDENTIFY), because those keys are the usernames.
• Changing somebody's roles doesn't sign them out. Switching them off does.

Related

• Sign-up and the mail server
• Owners, stewards and responsibilities
• The activity log
• Signing in and creating an account