Roles and permissions

What a role is

A role is a set of permissions, and every login in your company has exactly one — your own staff, the customer contacts who use the portal, and your partners.

Eight roles are created for your company when you sign up: six for staff, and one each for a customer and a partner portal login. They are your copies. Every company gets its own set, editing yours changes nothing for anybody else, and the ones marked Seeded at signup are the defaults rather than anything locked.

What the page does not do is add or rename roles. The set is fixed; what you change is what each one allows.

Reading the matrix

Roles open one at a time, and each is summarised where it sits — "10 of 36 permissions granted" tells two roles apart without opening either.

— open the full-size screenshot

Inside, the ten areas run down the side and the four actions run across: Create, Read, Update, Delete. Each area says in a line what granting it actually opens, because the question being answered here is "should this role be able to…", and the name of the area alone does not answer it.

The All column at the end sets all four at once, which is how most of these rows actually get set.

Four entries are worth reading closely.

• Staff & roles governs staff accounts, this table — and inviting anybody at all. Sending a customer contact their portal login is a staff-management permission, not a customer one, which is the single most surprising line on the page.
• Billing is your company's own Shipina subscription. Only Company Admin has it by default, read-only; give it to an accounting role if that is who should see what you are paying.
• Notes covers the internal notes your staff leave on a booking, quote, invoice, customer or partner. Every staff role has all four by default, and the customer and partner roles have none — notes never leave your staff, whatever this table says. Delete here only ever means a note somebody wrote themselves: nobody can edit or remove anybody else's.
• Activity log opens Settings → Activity, your company's record of what it did (see The activity log). Company Admin alone has it by default, read-only, and like notes it never reaches a portal login whatever this table says. The other three ticks do nothing: nothing writes or deletes an entry on request.

Without Read, nothing else takes effect

A role granted Create, Update or Delete on an area it cannot Read has been granted nothing. It cannot reach the page those actions apply to, so none of them can ever be used.

The table stores exactly what you tick — it is not an error, and nothing is silently corrected — but the row says so as soon as it happens. If you mean a role to do anything at all with an area, tick Read.

Changing one, and when it takes effect

Each tick saves on its own, immediately. A failure puts the checkbox back where it was and says what went wrong above the roles, so a box that snapped back was never saved.

Enforcement is server-side and takes effect at once — the next request that person's browser makes is already judged against the new permissions. What takes a moment longer is their screen: the buttons their app has decided to show are refreshed when it next reads their permissions, which happens on load. Nobody has to log out and back in.

Two reasons the table may be read-only

The page always loads and the matrix always reads. A tier that does not sell role editing still has staff who need to know what each role allows, and being able to find out what you are permitted to do is not the same permission as changing it.

So there are two separate walls, and the notice says which one you have hit:

• Your plan does not include editing them. The seeded defaults stay in force, and upgrading is what makes the checkboxes live. This is the notice shown when both apply, because it is the one somebody can act on.
• Your own role cannot change this table. Editing permissions needs the update half of Staff & roles — somebody who has it can do it for you.

Three limits no permission lifts

A role is not the only thing standing between a person and an action, and these three are worth knowing before you go looking for a checkbox that does not exist.

1. Your plan's ceilings. No permission adds a customer, a partner, a staff seat or a quote beyond what your plan allows. Those are refused at the moment the record would be created, whatever the role says.
2. Cost figures are staff-only. Your buy price, the kickback and your profit are stripped from everything a customer or partner account is sent, by the server, regardless of the permissions their role carries. You cannot grant a customer contact sight of your margin by ticking a box, and you cannot do it by accident either.
3. An unpaid Shipina invoice makes the whole workspace read-only. While a company is past due, every role in it can read and none can write. That is a billing state, not a permission, and the only way out of it is on the billing page.