Users and access

Access control has two halves: the users who log in, and the roles that decide what each user may do. Both live near each other, and the Profile page lets each person manage their own account.

The permission model in plain terms

Every permission is a feature area plus an action. Feature areas are things like Bookings, Customers, Banks, or Mail. The actions are:

Action	What it allows
View (read)	See and list records — the foundation. Without View, the other actions are usually unreachable.
Create	Add new records.
Edit (update)	Change existing records.
Delete	Remove records. Reserve for trusted staff.
Self	Act only on the user's own records (their profile, their to-dos, their work log).
All	The whole area at once — every action. Grant only to fully trusted roles.

Above all of these sits Administrator, which bypasses every check. Keep the number of administrators small.

Gurita ships with ready-made roles — Admin, Editor (front desk), Accountant, Auditor, Employee (read-only day-to-day), and the external Client, Agency, Customer, and Guest roles. Start from the lowest role that fits and only build a custom role when none does.

Role	Best for	What they can do
Admin	Owner / system administrator	Everything; bypasses every permission check and asset restriction.
Editor	Reservations / front desk	The full booking workflow — create and edit bookings, take payments, manage on-site charges. Read-only on most reference data (rooms, prices, customers).
Accountant	Finance / bookkeeping	Full access to banks, bank entries, booking payments, customers, agencies, pricing, and offers.
Auditor	Reviewer	Like Accountant, but read-only on the money side.
Employee	General staff	Read-only day-to-day data, plus their own to-dos, media uploads, and text blocks. No finance, no email sending.
Client / Agency / Customer	External logins	See only their own linked employee, agency, or customer record.
Guest	Public / not logged in	Public endpoints only, such as the booking widget.

Tip: Grant View first, then add Create/Edit/Delete as people actually need them. Guard the "keys to the kingdom" — User Roles, System Connections, Payment providers, Mail accounts, and Settings — for administrators only.

Permission areas

Permissions are grouped by the part of the business they control. Every area supports the same six actions above, so you build a role by picking the areas a person needs and then ticking the actions within each. The main areas:

• Bookings & guests — Bookings, Booking on-site, Booking payments, Booking comments, Customers, Customer notes, Referral codes, To-dos, Forms and form definitions.
• Bookable assets — Resorts, Vessels, Rooms, Room types, Tours, Schedules.
• Pricing & offers — Prices, Price variants, Supplements, Specials (and special groups), Global tax, Currency, Terms, Commission.
• Diving — Dive center, Dive-center guests, Dive log, Dive sites, Dive types, Dive boats, Dive plans.
• Finance — Banks, Bank entries, Payments, Payment providers, Export.
• Communication — Mail, Mail templates, Mail accounts, Mail schedule, Mail queue, Notification settings, Text blocks.
• Products, POS & media — Products, Point of sale, Media, Events.
• Staff & access — Users, User roles, Employees, Work logs.
• System & integrations — Settings, Booking widget, System connections, Xero, Poster, SU API, AI.

Booking sources, booking categories, and allowed arrival/departure rules come with Bookings access — they aren't separate areas.

Note: A few areas shown in the role editor are placeholders for planned features and have no effect yet (for example activities, inventory, supplier, operator, transaction, and the account chart entries). Leave them off unless support tells you otherwise.

Users

Where: Settings → Users (/users)

User list

The list shows each account with a status dot — green (active and verified), amber (inactive or not yet verified), or red (blocked) — plus name, email, the assets they're limited to (or "all"), any linked agency, and the user type. Filter by type (staff, customer, agency).

To create a user:

1. Click Create (or use the + create menu). Enter the person's name, email, and phone.
2. Assign a role and, if needed, restrict them to specific assets.
3. Save. If email verification is enabled, the user receives a link to verify their address before they can log in.

Opening a user shows tabs for User details, Password, Login history, Notifications, and Settings. On the details tab you set:

• User type — staff, customer, or agency. Customer and agency accounts link to a customer or agency record so they can use the guest / partner portal.
• Asset restriction — limit the account to specific resorts, vessels, or dive centers (and specific banks when the Bank module is on). Leave these empty to give access to all assets.
• Account status — Verified (email confirmed), Active (may log in), and Blocked (access revoked). The status dot in the list reflects these. Tick Reset password to force a reset on next login.

The Settings button on this page (gear icon) opens account-wide options: whether registration is allowed, whether new users need admin activation, whether email verification is required, and which templates the verification emails use (with a separate template for CRM / club portal users).

Open any user to edit them; delete removes the account.

User Roles

Where: Settings → User Roles (/userroles)

A role is a saved bundle of permissions you assign to users. The role editor lays out every permission area in category accordions: expand a category, then tick the actions for each area in the matrix.

User role editor

The matrix columns are All, Create, Edit, Delete, View, and Self — ticking All covers the rest for that area. Below the matrix, a role can also carry fine-grained overlays:

• Booking categories — limit the role to specific booking categories (leave empty to see all).
• POS toggles — allow pay, show all, edit price, delete item, move item, see today's sales, cash payment, and hide on-site prices.
• Home / Navigation / Report / Show toggles — decide which dashboard widgets, menus, reports, and on-screen actions (occupancy, payments, check-in/out, end-of-day, housekeeping, guest forms, on-site discounts with a maximum %, currencies, comment types) the role sees.

Note: If a role carries permission entries the editor doesn't recognise (for example rights set by an older version or by support), they are preserved and shown read-only under Unrecognized entries — never silently dropped, so saving a role can't quietly remove access it didn't display.

To create a role:

1. Create a role and name it.
2. Expand the category accordions and tick the actions each area needs. Ticking All for an area covers Create, Edit, Delete, View, and Self at once — use it only for fully trusted roles.
3. Set any category, POS, or view overlays.
4. Save, then assign the role to users on the Users page.

Tip: To make a variant of an existing role, use Copy in the role list and adjust it — faster and safer than rebuilding from scratch. If a built-in role is almost right, copy it rather than over-granting.

Warning: The Administrator role bypasses every permission check and every asset restriction. Keep the number of administrators to a minimum, and give everyone else a named role so you can see and adjust exactly what they can do.

Warning: The User Roles page effectively controls who can grant permissions. Restrict it to administrators.

Your profile

Where: Profile (/users/profile)

Every user can manage their own account here, across tabs:

• User details — name, email, phone, avatar, and a Change password action (changing your password logs you out).
• Bookings — your own bookings (staff only).
• Notifications — which notifications you personally receive, grouped by section.
• Settings — your language, currency, interface zoom, default POS location, and display preferences.
• Login — your recent login history.

Your profile

Email verification

Where: the verification link in the invitation email (opens the User verification page).

To require email verification:

1. On the Users page, open Settings (gear icon).
2. Turn on email verification required.
3. Choose the verification email template (and, for club / portal logins, the separate CRM template).
4. Save. From now on, every new account must confirm its address before it can log in — the account shows an amber status dot until it does.

When verification is required, a new user clicks the link in their email and lands on a confirmation page. On success they can go straight to login; if the link is invalid or expired, they see an error and can return to login to request help. Nothing to configure here — it's the landing page for the link.

Who can access this: Users and roles require the Users and User roles permissions (administrators). Everyone can reach their own Profile; most staff need only the Self action on Users.

---