Members and permissions

Two separate questions decide what you can do with a project. Visibility decides whether you can open it at all: you created it, you are on a team attached to it, or you are an organization administrator. Permissions decide what you can do once it is open, such as run a step, approve a document, stop a run, bind the agent or push to a repository. Permissions come from your role in PolyX. This page covers both, the Members tab, and what you see when a permission is missing.

Two layers: visibility and permissions

Drawing diagram…

• Visibility is worked out from the project's creator, its attached teams and your organization role. Being able to see a project never gives you any action on it.
• Permissions are PolyX module grants on your role. Having a grant never lets you see a project that visibility hides from you.
• Everything is scoped to the organization you are signed in to. A project that belongs to another organization looks exactly like one that does not exist.

Who can see a project

You can open a project in your current organization if any of these is true:

A project with no teams attached can be opened only by its creator and by organization administrators.

A Whole team attachment follows the team's live roster. When someone joins the team in PolyX, they can see the project after the next organization sync. When someone leaves, they lose it. A Pick members attachment lists specific people and does not change when the team does.

If you open a link to a project you cannot see, the page shows Project not found with "The project may have been deleted or you do not have access." The same page appears for a project that really was deleted, and for a project in another organization.

The Members tab

The project's Members tab lists the people who can open the project through its teams:

• A count badge, such as "5 people · 2 teams". A person on two attached teams is counted once.
• A Created by line with the creator's name and email.
• One card per attached team, labelled Whole team or Selected, listing each member's name and email. The creator carries a Creator badge.
• No teams attached, when the project has none. It explains that only the creator and org admins can open the project.
• "No members resolved for this team (it may have no synced roster yet)." appears for a team whose roster has not synced yet.

The Members tab is read-only. You cannot attach, change or detach teams there. The bridge has endpoints that do these things, and they need the Members grant (see the table below). Organization administrators are not listed on the tab, even though they can open the project.

Permissions: what each action needs

Alara Code checks six PolyX modules. Each one has its own grants. A grant on one module gives nothing on another, so Projects with every action does not include Projects › Run.

Each module has the actions create, read, update and delete. manage grants all four on that one module.

Action reference

A few things are worth knowing:

• Approving is the same grant as running. Approving moves the pipeline forward, so it needs Projects › Run › create, like starting a step.
• Creating a project is not enough to run it. The creator has no automatic rights. Whoever creates a project still needs Run, Abort, Binding and Integrations to drive it.
• Deleting all projects removes only the projects you created in the current organization. Neither delete works while a command is running.
• Your own profile and account settings need no module grant.

Organization administrators

Alara Code treats you as an organization administrator when your PolyX permission is named as one, for example "Organisation Administrator", "Organization Admin", "Admin" or "Owner". An administrator:

• sees every project in the organization;
• is the only person who can force an organization sync;
• gets no extra actions from being an administrator. To run, approve, stop, bind or push, the administrator's role must hold the same module grants as everyone else's.

When you lack a permission

The app disables a control before you click it when your role lacks the grant. Hover over the disabled control to see why. The tooltip reads Needs followed by the module and action, for example "Needs Projects › Run › create" or "Needs Integrations › update".

Where a whole area is blocked, the app says so in place:

• SDLC Studio. When you cannot run steps, the message box is replaced by a note and the step rail's run buttons are disabled with the same reason. The note's title is the missing grant, followed by: "Your role does not include Projects › Run › create. Ask an organization administrator to add it to your role in PolyX." Approve and Request changes are disabled with the same reason. Stop is disabled when you lack Projects › Abort.
• No agent bound. If you have the grant but the project has no agent, the note reads "No Alara agent bound" and "Bind one of the organization's agents in Project Settings › Agent before running a step.", with an Open Project Settings link. A missing grant is reported before a missing agent.
• Repository tab. When you cannot read the integration, the tab shows "Repository settings are not available to you" and names the missing grant.

If the app could not work out your grants before you clicked, the bridge still refuses the request. You then see a toast titled Permission required with the same sentence: "Your role does not include module › action. Ask an organization administrator to add it to your role in PolyX."

The fix is always in PolyX. An organization administrator adds the module and action to your role there. Changes can take a minute to reach Alara Code, because both the bridge and the app cache your grants briefly.

Under the hood

• Every protected bridge route is mapped to one module and action in bridge/src/config/access-control.ts. The action comes from the HTTP method (GET is read, POST is create, PUT and PATCH are update, DELETE is delete) unless the route overrides it. A refusal is 403 PERMISSION_DENIED with { module, action } in the error details.
• Enforcement follows the deployment's ACCESS_CONTROL_MODE: off checks nothing, audit logs what it would refuse without refusing, and enforce refuses. The app disables controls only when the bridge reports enforce. In the other modes, anyone who can see a project can use every control on it.
• A protected route with no mapping is refused with ROUTE_NOT_MAPPED under enforce. It is never silently allowed.
• Visibility is one predicate (bridge/src/lib/projectScope.ts) that every project read and write loads through, always within the request's organization.

For how sign-in and the organization header reach the bridge, see Authentication and tenancy. For each endpoint's permission, see the API reference.