Identity and resource permissions

Beyond Accounts decides who you are and which organizations you belong to. Each product decides what you may do with its own resources. This page says who decides what.

Availability: Experimental
Evidence: Read from source
Explanation

The problem this solves

When something is refused, you need to know whom to ask. The answer depends on which of two questions was being asked: "who are you?" or "may you do this here?". They are answered by different parts of Beyond.

Who decides what

Question	Decided by	Examples
Who is this person?	Beyond Accounts	Signing in, the sign-in methods of an account, whether an address was confirmed
Is their login still valid?	Beyond Accounts	Expiry, sign-out, sign-out everywhere, suspension
Which organizations do they belong to, with which role?	Beyond Accounts	Invitations, role changes, removal, last-owner protection
May they see or change this resource?	The product that owns the resource, on every protected operation	In Delegate: reading a project, registering a request, approving, launching, requesting a deployment
May a machine do this?	The product, with credentials that are not people	In Delegate, an agent's credential is bound to one project and can never take a human decision

The Accounts interface says it on every organization page: "A role here decides membership. What someone may do in Workspace, CDN or Delegate is decided by that product."

Consequences you will notice

Changing a role in Accounts does not change what you can do in Delegate. Ask a Delegate workspace administrator instead.
A product credential changes nothing common. The session a product receives lets it recognize you and end itself. It cannot change your account, attach a sign-in method, create an organization, invite anyone or sign you out everywhere. Only the session you hold at Accounts, used from the Accounts interface, does those.
Signing in with GitHub gives Beyond no right over your repositories, and signing in to Delegate gives it no access to your cloud accounts. Provider connections are configured separately.
"Not found" can mean "not yours". Accounts and Delegate both answer a resource you may not see exactly as they answer one that does not exist, so that an address or identifier never confirms that someone else's organization or project exists. In Accounts the sentence is "That is not here."; in Delegate, "That record does not exist or you cannot access it."
A refusal and an outage are different answers. "You do not have access to this." and "Your role does not allow this action." are decisions. "Accounts is not answering right now. Nothing was changed." and "Beyond Accounts is not answering. Nothing was changed; try again shortly." are not: nobody decided anything. A product that cannot reach Accounts refuses after a short tolerance and never approves in the meantime.

The two layers inside Delegate

Delegate itself separates two things, and both must allow an action:

Layer	Comes from	Decides
Role	Your seat: Administrator, Member or Viewer	The kind of action you may ever take
Permission	A grant in one project: Read, Register requests, Comment, Take decisions, Configure the project	Whether you may take it in that project

An Administrator holds every permission in every project of the workspace. A Viewer only reads, whatever a grant records. The full table is in Workspace and collaboration.

Whom to ask

The refusal	Ask
You cannot sign in, or your account is suspended	The people who run your Beyond installation
You are not a member of an organization, or your role there is wrong	An Owner or Administrator of that organization
You have no seat in Delegate, or cannot see a project	An Administrator of that Delegate workspace
You can see a project and cannot act in it	The same administrator, for a permission in that project

Next action

See the concrete rules: Organizations in Accounts and roles and access in Delegate.

The problem this solves#

Who decides what#

Consequences you will notice#

The two layers inside Delegate#

Whom to ask#

Next action#