Skip to main content
This page explains how user accounts and access control work today.

​
Best for

  • onboarding staff
  • controlling who can view or edit different parts of the system
  • deciding who can approve corrections and reviews

​
Current access model

AquaOps assigns permissions directly to each user — there is no separate “Roles” page or reusable role template to configure first. When you add or edit a user, you check off exactly the permissions they need from a grouped checklist (Organization, Locations, Pools, Users, Chemical Records, Maintenance Logs, Compliance, Forms, Form Submissions), plus which locations they can access. This is simpler to reason about for a small team, at the cost of having to re-check the same boxes for every user with a similar job — see Recommended permission sets below for a way to make that consistent.

​
Users

Go to:

​
Creating a user

Click Add user and provide:
  • name
  • email
  • whether they’re a CPO (certified pool operator)
  • one or more permission keys, from the grouped checklist
  • which locations they can access
After creation, AquaOps generates a temporary password and shows it once.
Copy the password immediately and share it securely with the user. The password will not be shown again after the dialog closes.

​
Editing an existing user’s permissions

Open a user’s row actions and select Edit permissions to change their permission checklist or location access at any time — the same checklist used when the user was created.

​
User status

Users can be active or inactive. Inactive users should not be able to continue normal use of the app.

​
Permission keys

Every permission is a module:action key. A user can hold any combination.

​
The org:manage wildcard

org:manage grants every permission below automatically — full access to organization settings, users, locations, pools, and every record type. Grant it sparingly; it’s the equivalent of an “admin” toggle.

​
Example permission keys

  • chemical_records:view
  • chemical_records:edit
  • chemical_records:create
  • chemical_records:correct — approve or reject a correction to an already-saved chemical record; without it, staff can still request one, it just waits for review
  • maintenance_logs:view
  • maintenance_logs:create
  • maintenance_logs:edit
  • maintenance_logs:correct — approve or reject a correction to an already-saved maintenance log
  • compliance:view
  • compliance:manage
  • forms:view — see and author form templates (Settings > Forms) — separate from actually filling one out
  • forms:create
  • forms:edit
  • form_submissions:create — fill out and submit forms day to day
  • form_submissions:view
  • form_submissions:manage — review, approve, reject, or request changes on submitted forms
  • form_submissions:correct — approve or reject a correction to a form submission that’s already been approved or rejected
  • locations:create / :edit / :delete
  • pools:view / :create / :edit / :delete
  • users:view / :create / :edit / :delete
  • org:manage — wildcard, full access
Locations have no separate view permission — location names aren’t sensitive, so every user can see them for basic navigation (filters, pickers). There’s no built-in role template, so keep a short written reference for your organization (a spreadsheet, an internal wiki page, or just this section annotated with your own notes) describing the permission sets you actually use — for example:
  • Admin — org:manage
  • Manager — view/create/edit/correct on chemical records and maintenance logs, compliance:manage, form_submissions:manage
  • Operator — view/create on chemical records and maintenance logs
  • Read-only — the :view keys only
Re-apply the same checklist by hand for each new user in that category. If your organization outgrows this (dozens of users, frequent onboarding), that’s a signal to request a reusable role/template feature rather than working around it manually.

​
The admin user

There’s no protected “admin” role name in the current model — org:manage is just a permission key like any other. Make sure at least one active user always holds it, since it’s the only way to grant or revoke everyone else’s access.

​
Typical walkthrough

1

Decide your permission sets

Write down (outside the app) the two or three staff categories your organization actually needs and which permission keys each one gets.
2

Open Users

Open Settings > Users.
3

Add staff

Add each staff member, checking the permission keys and location access for their category.
4

Deliver credentials

Copy the one-time temporary password and deliver it securely.
5

Manage access

Use Edit permissions to adjust an existing user, and inactivate users when they should no longer have access.

​
Suggested screenshots

  • users list
  • add user dialog with the permission checklist
  • edit permissions dialog on an existing user