Roles, Permissions & Trust

A notification system is only trustworthy if the people making changes are the people who should be allowed to. OneEnv keeps this simple on the surface — three roles — but resolves it precisely underneath.

• Owner — full control, plus the only role that can hand off ownership itself, through a dedicated transfer flow the generic role editor deliberately can't touch — and the only role that can archive or (after a 30-day grace period) permanently delete the workspace.
• Admin — the same write power as Owner everywhere else.
• Member — read access, plus whatever specific permission they've been explicitly granted, per service: none → view → edit → service_admin, where service_admin is the level that can approve or reject that service's incoming impacts.

One asymmetry is worth knowing: editing a value from the workspace-level Env Master screen always requires Owner/Admin, while editing that same value from a service's own page only requires "edit" permission on that specific service. Two different questions — "can you manage the config catalog" vs. "can you affect your own service" — enforced server-side on every single write, not just mirrored in the UI. A permission grant is cached for ten minutes and invalidated instantly the moment it changes, so a revoked grant takes effect on the very next request.

The Branch/Merge layer added a second, independent gate on top of this rather than replacing it. Staging a change still runs the exact same permission check the direct edit used to — editing a service's env value still needs "edit" on that service, proposing a column still needs plain membership, and so on. Merging the branch that carries it is a completely separate decision: always Owner/Admin, always on the whole branch at once, regardless of who staged what inside it or what permission they used to do so.

Trust isn't just about who can write — it's also about who can even see something exists. A Member with a grant on exactly one service only ever sees that service in their list, only ever gets notified about changes touching it, and gets a clear "you don't have permission" state instead of a service quietly missing with no explanation if they navigate to it directly. The same visibility rule follows them everywhere derived data shows up — notifications, the audit History, and every Workspace Report aggregate are all filtered to what the viewer is allowed to see before anything is counted or paginated. Owner and Admin still see everything, same as they always could — this gate only narrows what a Member's view resolves to, it never widens anyone else's.