Changelog

​

New features

• A full Swim Lessons module is now live. AquaOps now supports classes, student rosters, curriculum and level management, report-card authoring, and two-stage review before a card is published to families.
• Swim lesson settings have their own dedicated home. The settings area now includes Settings > Swim Lessons for curriculum editing, lesson-level management, comment prefills, and report-card approval settings.
• Published report cards can be looked up by families without an account. Parents and guardians can use the public lookup flow to find a published report card using the student’s name plus date of birth or the last 4 digits of the guardian phone on file.

​

Updates

• Navigation now uses the final Swim Lessons naming everywhere. The main app nav points to Swim Lessons at /lessons, and the settings nav now uses the matching /settings/swim-lessons URL instead of the older lesson-levels slug.
• Approval can be configured per organization. Report-card review supports co-teacher review plus final approver review, with each stage set to require either any reviewer or all reviewers depending on the organization’s settings.

​

New features

• Terms, Privacy, and EULA pages are now live. AquaOps now publishes dedicated Terms of Service, Privacy Policy, and End User License Agreement pages on the public site.
• Required legal consent at account entry points. New users setting up an organization and invited users accepting an invite must now explicitly agree to the legal documents before continuing.

​

Updates

• Legal links are now wired across the product. The marketing site, authenticated app shell, and sitemap all include the legal pages so they are reachable from both public and signed-in surfaces.
• Processor disclosures now match the real stack. The public privacy documentation reflects the current vendors in use, including Clerk, Supabase, Vercel, Resend, PostHog, and Google Maps Platform.

​

New features

• Submit a support request from inside AquaOps or from the public site. A new Help page is available both on the public marketing site (no account needed) and at Settings > Help for signed-in users, who also see the history of their own tickets there.
• Org admins can see their organization’s tickets, not just their own. Anyone with the new ticket:org permission can view and comment on every support ticket submitted by their organization.
• AquaOps staff reply from an internal queue. Replies go out by email directly to whoever submitted the ticket, and tickets can be marked resolved and reopened.

​

Updates

• New ticket:own and ticket:org permissions. Submitting and viewing support tickets now requires the ticket:own permission — previously implicit for any signed-in user. If a role should be able to submit tickets, assign ticket:own to it in Users and Roles; ticket:org additionally opens visibility to the whole organization’s tickets.

​

New features

• A public AquaOps site. The marketing site now has a full homepage, a Features page, a Security & Data Handling page explaining how organization data is isolated and protected, and separate About and Contact pages.
• FAQ page. A public FAQ covering product scope, multi-location/multi-pool support, compliance tracking, and how to get help.

​

Updates

• Mobile navigation added to the site header, and FAQ and Help are now in the main site navigation instead of footer-only links.

​

Bug fixes

• Converting a tester to a full user no longer leaves a duplicate archived entry. The original tester row was staying visible in the archived-testers list even after the person became an active login user under the same identity.
• User creation no longer fails for single-word names. Creating a user or granting login access with no last name (a one-word display name) was being rejected during account creation; names are now handled correctly either way.
• Add User and Grant Login Access dialogs no longer overflow the screen. With the new permissions checklist and role selector, these dialogs could grow taller than the browser window with the Save button unreachable. The field area now scrolls internally instead.

​

New features

• Define named roles instead of hand-checking permissions per person. Admins with the new roles:manage permission can create named permission sets — for example, “Pool Operator” or “Front Desk” — from a new Settings > Roles page, then assign a user to one from the Edit Access, Add User, or Grant Login Access dialogs instead of checking each permission individually.
• Editing a role updates everyone assigned to it. Change a role’s permissions once and every user currently following that role picks it up immediately.

​

Updates

• Deleting a role doesn’t strip access. Users assigned to a deleted role keep their last-known permission set — they’re just detached from future changes to that role.

​

Updates

• AquaOps moved to a new provider (Clerk) for sign-in, sessions, and organization membership. You’ll see a refreshed sign-in and sign-up experience. Account security — password, two-factor authentication, active sessions — now lives under your account profile menu instead of Settings > Security. Existing accounts, organizations, and permissions all carried over; no action is needed to keep using AquaOps as before.
• Kiosk PIN sign-in is unaffected. Shared-device sign-in via PIN continues to work exactly as before for end users.

​

New features

• Opt out of persistent sign-in on shared computers. The login page now has a Keep me signed in checkbox, checked by default. Uncheck it on a shared or public computer and your session ends when you close the browser instead of staying signed in.

​

New features

• Add your own fields to a pool’s chemical log. From a pool’s chemical-records settings, admins can now define custom fields — number, text, or yes/no — that appear on that pool’s chemical record form alongside the standard readings. Mark a field required to make sure it’s always captured.
• Custom values show on the record. Anything entered in a custom field appears under Additional Fields on the record’s detail page, and edits to it go through the same correction flow as the rest of the record. See Chemical Records.

​

New features

• Two-factor authentication for admin accounts. Accounts with organization-management permissions can enroll in TOTP-based two-factor authentication — scan a QR code with any authenticator app, confirm with a 6-digit code, done. AquaOps nudges these higher-privilege accounts to enroll rather than requiring it; once enrolled, a code is requested at each new sign-in.

​

Updates

• Dependency security patches. Resolved 10 known Next.js framework vulnerabilities via a dependency upgrade. No action needed on your end.
• Internal support tooling. AquaOps staff now have an internal, read-only panel for account support and troubleshooting, with every access logged for audit.

​

New features

• PIN sign-in for shared devices. Set up a tablet or workstation as a kiosk from Settings > Organization, and anyone can walk up, pick their name, and enter their personal PIN to get the full app with their own real permissions — not a stripped-down kiosk view. Set your own PIN from Settings > Kiosk PIN.
• Automatic idle sign-out. Kiosk sessions sign out after 5 minutes of inactivity and return to the kiosk sign-in screen, so a shared device never sits logged in as the last person who used it.
• In-progress work is autosaved. Chemical records, maintenance logs, and form submissions now periodically save a local draft as you fill them out, so an idle timeout or accidental navigation on a kiosk doesn’t lose what you’d started entering.

​

Updates

• Lockout after repeated wrong PINs. Five incorrect attempts locks an account out of kiosk sign-in for 15 minutes; an admin can reset a forgotten PIN from the Users settings page.
• Device enrollment is admin-only and physical. Enrolling a kiosk device has to happen on the device itself, from an admin’s own session — there’s no token to copy or share, and a revoked device is locked out immediately.

​

Updates

• Anonymous product analytics are back, with an updated approach. After rolling back our previous analytics trial (noted here on July 22), we’ve re-enabled lightweight, privacy-conscious product analytics to help us understand which features are actually useful and where people get stuck. As before, this is separate from and unaffected by page-performance monitoring, which was never removed.

​

New features

• Sign up without an invite. A new public Sign up page lets anyone create their own organization and account directly — no admin setup required. Email verification is required before the account can sign in.
• Invite teammates by email. Admins can invite a new user from Settings > Users; the invite link works whether the recipient is brand new to AquaOps or already has an account and is joining a second organization.
• Belong to more than one organization. Accounts that belong to multiple organizations now get an org switcher in the header. Permissions and location access are scoped per organization, so switching orgs only shows what you’re actually granted there.

​

New features

• Corrections replace silent edits on saved records. Chemical records, maintenance logs, and form submissions (once approved or rejected) can no longer be edited and silently overwritten. Every change to an already-saved record now goes through a correction: you’re required to give a reason, and the original values are preserved alongside the new ones.
• A “Corrected” badge and full history on the record itself. Any record with at least one approved correction shows a Corrected badge next to its title. Scroll to the Corrections section on the record’s own page to see every correction’s reason, a before/after field comparison, who requested it, who reviewed it, and when — no separate history page to hunt through.
• Two paths depending on your permissions. If you hold the new *:correct permission for that module, your correction applies immediately (and is recorded as self-reviewed, for the audit trail). Otherwise, it’s held as pending until someone who does hold *:correct approves or rejects it — the record stays unchanged in the meantime.
• Where this applies today:
  • Chemical Records — editing any saved reading
  • Maintenance Logs — editing any saved entry
  • Form Submissions — editing a submission that’s already been Approved or Rejected (submissions still in draft, submitted, or changes-requested keep their existing edit flow)

​

Updates

• New permissions. chemical_records:correct, maintenance_logs:correct, and form_submissions:correct control who can apply a correction immediately versus who needs another reviewer to sign off. Assign these in Users and Roles — without one of these, staff can still request a correction (as long as they already have edit access to that module), it just won’t take effect until reviewed.
• Rejecting a correction requires notes. Same pattern as rejecting a form submission — a reviewer has to explain why, so the requester knows what to fix.
• See Chemical Records and Maintenance Logs for the full walkthrough.

​

New features

• One-click Location, Pool, and Signature fields. The template builder now has a Form-level fields checkbox row above the section list: check Location, Pool, or Signature and it’s automatically added to the top of the submission form — no need to build it as a regular question. Unlike a normal field, it can’t be dragged, reordered, or edited in place; the checkbox is the only control.
• Pool choices narrow to the selected location. Once someone filling out a form picks a location (whether it’s one of these new form-level fields or a location field built the regular way inside a section), the pool picker right after it only lists that location’s pools. Pick a different location and the pool list updates to match.

​

Updates

• Location/Pool quick-add buttons retired. The per-section + Location field / + Pool field buttons introduced last week are replaced by the checkbox row above. If you already added one of these fields inside a section, it still works exactly as before — nothing breaks, but new templates should use the checkbox instead. You can still add a plain Location, Pool, or Signature field inside a specific section the regular way (via Add field) if you need more than one, or need it somewhere other than the top of the form.

​

Bug fixes

• Signature capture now tracks the cursor correctly. On some screen sizes and zoom levels, the ink from a drawn signature could land slightly off from where the mouse or finger actually was. The signature pad now accounts for the difference between its on-screen size and its drawing resolution, so the line follows the cursor precisely.
• Regular staff can now see their own form submissions. A permissions gap meant that anyone without template-authoring access (forms:view) — which is normal for staff who only fill out forms, not build them — got a “not found” error opening their own submitted form, and couldn’t see published templates on the Submit a Form picker at all. Both are fixed; filling out and reviewing forms no longer requires template-editing access.

​

New features

• Review actions on submitted forms. Any submission in Awaiting review now shows Approve, Request changes, and Reject buttons for reviewers. Each action stamps the submission with the reviewer, the review time, and (optionally) notes, so completed forms carry a clear audit trail of who signed off and when.
• “Changes requested” bounces a form back to the submitter. Instead of rejecting outright, a reviewer can send a submission back with required notes explaining what needs to be fixed. The form becomes editable again for the original submitter (just like a draft), and it flows back through the same submit → review cycle when they’re ready.
• Reviewer notes required on reject and request-changes. Rejecting a submission or requesting changes both require notes, so submitters always get a reason. Notes are optional on approvals.
• New submission statuses. Submissions now progress through Draft → Awaiting review → Approved / Rejected / Changes requested. Approved and rejected are terminal and read-only; changes-requested is editable and reusable.

​

Updates

• Approval permissions. The Approve, Reject, and Request changes actions are gated behind the existing form_submissions:manage role permission, so only reviewers see them — day-to-day submitters (form_submissions:create / :view) are unaffected. Assign roles in Users and Roles.
• Reviewers can’t self-approve their own submissions. Even if a reviewer submits their own form, the approve/reject/request-changes actions enforce the manage permission explicitly at the server, so the same person can’t push a form all the way through to Approved on their own.
• Forms status page refreshed. Forms and Exports Status now lists approvals as live and updates the “still planned” list accordingly.

​

New features

• Attachment field type. A new Attachment field is available in the form template builder, so templates can require or optionally collect files — photos of equipment, scanned paperwork, incident evidence — right alongside other answers. Uploads are capped at 10 MB per file.
• Real signature capture at submission time. Signature fields now render as a canvas signature pad in the submission form instead of a typed-name placeholder. Submitters sign with a finger or stylus (or mouse on desktop) and the drawn signature is stored with the submission as evidence.
• View and remove attachments in draft. While a submission is still a draft, the submitter (or a manager) can preview uploaded files and remove them before submitting. Once the submission is finalized, attachments are locked along with the rest of the read-only receipt.

​

Updates

• Scoped access to uploaded files. Only the submission’s owner and managers with the form_submissions:manage permission can view or delete an attachment, and only while the submission is still a draft. Assign roles from Users and Roles.
• Safe upload rollback. If saving an attachment record fails after the file lands in storage, the uploaded file is automatically removed so nothing is left orphaned.

​

New features

• Recurring form schedules. You can now put any published form template on a fixed cadence — for example, “weekly facility walkthrough every 7 days” — scoped to a specific location and pool. Manage them from the new Form Schedules page (available from Custom Forms > Schedules). Due dates are computed from the cadence and the most recently submitted linked form, so there’s no separate task queue to keep in sync.
• “Due” list for overdue forms. A new Forms Due page surfaces every schedule that’s past its next due date, with the template, location, pool, and how overdue it is. Use it as a daily worklist to see what still needs to be filled out.
• One-click “Start form” from a schedule. From either the schedules list or the due list, Start form deep-links into the new-submission flow with the template, location, pool, and originating schedule already pre-filled — no re-picking from dropdowns. Once you submit, the schedule automatically drops off the due list.

​

Updates

• New “manage” permission for form schedules. Creating and deactivating schedules is gated behind the existing form_submissions:manage key, so managers can set up recurring forms without granting broader template-authoring rights. Day-to-day submitters continue to use form_submissions:create and form_submissions:view. Assign roles in Users and Roles.
• Forms status page refreshed. Forms and Exports Status now lists recurring forms as live and updates the “still planned” list accordingly.

​

New features

• Fill out and submit custom forms. The Custom Forms area in the primary navigation is now a working submission flow — not a placeholder. From Custom Forms > New, pick any published template and (optionally) attach a location or pool, then fill it out and submit. This closes the loop on the form template builder that shipped earlier this week.
• Dynamic rendering that respects conditional logic. Every field type from the builder — short/long text, number, date, dropdown, multi-select, checkbox, multiple choice, and signature — renders inline in the submission form. Show/hide rules and formula conditions are evaluated live as you type, so follow-up questions appear only when they apply to your answers.
• Repeatable sections. Templates that use repeatable sections (for example, one row per pool or per piece of equipment) now expose Add and Remove controls at submission time, so you can capture as many entries as the visit requires without leaving the form.
• Inline validation before submit. Required fields, number ranges, and other rules from the template are checked as you go. If anything is missing or out of range, the submit button is blocked and each affected field shows a targeted error message — no more guessing which field the form is unhappy about.
• Read-only receipts after submit. Once a submission goes through, the form switches to a read-only view of exactly what was captured, so you (and anyone with access) can revisit the record as evidence without risk of accidental edits.

​

Updates

• “Custom Forms” navigation now points to the real flow. The primary-nav Custom Forms entry used to lead to a placeholder — it now opens the live submission picker. See Navigation and user experience for where it lives.
• Forms status page refreshed. Forms and Exports Status now lists the submission runtime as live and calls out what’s still planned next (submission-time signature capture, notifications, recurring forms, approvals, public links, and completed-form exports).
• Server-side revalidation. Every create, update, submit, and discard action revalidates the submission against the template on the server as defense in depth, so submissions that reach the database are guaranteed to satisfy the template’s rules — even if a client-side check is bypassed.

​

New features

• Form template builder is live. The form designer at Settings > Forms is now a fully working builder — not a placeholder. Admins and managers can author reusable templates for inspections, incident reports, and other structured recordkeeping, with nine field types (short/long text, number, date, dropdown, multi-select, checkbox, multiple choice, signature). Walk through the whole flow in Form Templates.
• Create templates from an existing checklist. From the templates list, use Create from checklist to seed a new template from a checklist template instead of starting blank.
• Richer conditional logic. Show/hide rules now support 16 comparison operators (equals, not equals, greater than, contains, starts with, is between, is empty, and more) instead of a single “equals” check. The operator picker automatically filters to only the operators that make sense for the source field’s type. See Conditional logic.
• Custom formula conditions. For rules that span multiple fields, switch a condition to formula mode and reference earlier fields by label — for example, [Pool Temp] > 85 AND [Chlorine] < 1. Formulas are validated as you type, and the parser flags the first invalid token so you can fix it in place.
• One-click explanation fields. Adding a follow-up “please explain” text field to a conditional rule is now a single action, so building forms that ask for context on out-of-range readings takes seconds instead of minutes.
• Smarter value pickers. For dropdown, multi-select, and multiple-choice fields, the conditional rule editor auto-populates the list of possible values so you can pick from real options instead of retyping them.
• Draft, published, and archived versioning. Templates carry a status. Drafts are freely editable in place; the next edit to a published template automatically rolls forward to a new version so anything referencing the previous version stays stable. Archived templates are hidden from active pickers.

​

Updates

• Existing form templates upgraded automatically. Any conditional rules you’d already built continue to work — they’re migrated to the new format the next time the template is opened. No action required.

​

Updates

• New role permissions for filling out forms. Two new keys — form_submissions:view and form_submissions:create — are now available when configuring custom roles, plus form_submissions:manage for reviewers. These separate day-to-day form filling from template authoring (forms:*), so you can, for example, let staff submit forms without granting access to edit templates. Assign them in Users and Roles.
• Hardened permission checks. We’ve expanded automated test coverage on the permission and admin-only checks that protect every action in AquaOps. No behavior change — this is a reliability investment to keep role-based access working correctly as new features ship.
• Page-performance monitoring enabled. AquaOps now reports anonymous Core Web Vitals (load time, interactivity, layout stability) from your browser so we can catch slow pages and regressions. No personal information, page content, or session recordings are collected.
• Product analytics temporarily removed. We’ve rolled back the in-app analytics and session replay integration that was previously being trialed. AquaOps is not currently collecting product usage telemetry or session recordings from your facility. We’ll share more when an updated approach is ready.

​

Bug fixes

• “Install app” prompts now work from the login page. The PWA manifest was being blocked for logged-out visitors, which silently disabled the browser’s install prompt on /login and any other unauthenticated screen. It’s now served correctly, so you can install AquaOps to your home screen or desktop without signing in first.