Documentation

Users, groups & security

Accounts, groups, Linux-style rights, record sharing, audit log and hardening.

Users

Users live under Settings → Users. Each user has a username, full name, email, language, a primary group, an optional expiry date and a deactivation flag. A user can also be marked root — root bypasses all rights checks, so keep that to one or two accounts.

For Google Workspace, each user also carries a google_workspace_email (the identity the service account impersonates), a calendar id and a Drive root folder id. See Google Workspace.

Groups

Groups (Settings → Groups) are the unit of sharing and of permissions. A user has one primary group and may belong to several more. New records are stamped with the creator and the creator’s primary group.

Rights

BillBoy uses the ApiGoat rights model, which will feel familiar if you know Linux file permissions. For every module a user (or group) gets three sets of rights — all, owner and group — each combining read, create, update and delete:

Set	Applies to
Owner	Records the user created
Group	Records created by anyone whose primary group matches one of the user’s groups
All	Every record in the module

Lists are filtered by these rules automatically: a salesperson with owner+group rights on Contacts sees their own and their team’s contacts, nothing else. The same filter applies to the REST API and to MCP tools.

A contact can be shared with additional groups from the Share tab on its record. Shared groups get read access through their group rights without changing who owns the record.

Route-level permissions

Beyond record rights, every route (list, edit, custom action, API endpoint) is registered in Settings → API RBAC with a public flag and the groups allowed to call it. This is what makes an endpoint like /api/v1/Contact reachable to one group and invisible to another.

Audit log

Settings → Users → Log records every login attempt with timestamp, username, result and IP. API calls are logged separately under Settings → API log, including the MCP calls made on behalf of a user.

Hardening checklist

Serve /.admin over HTTPS only; set app_status to production in .env.
Use one root account, protected by a long password, and give everyone else group rights.
Keep .env, secrets/ and the service-account JSON outside the web root or denied by the web server.
Run the cron user with the same permissions as the web user — not root.
Back up the database and the files/ directory; Drive-backed files are already on Google.

BillBoy is on-premise software. The runtime has been audited repeatedly over fifteen years, but the biggest risks are on the infrastructure around it: keep PHP, the web server and the OS patched.