Permissions

PDM never shows a user the whole platform — only the part they have been granted access to. That is why two people opening the very same screen can see a different number of stands and a different set of buttons. This page explains how permissions work from an ordinary user's point of view, and what to do when something is missing.

A permission = an action + a scope

Every permission granted to you has two parts:

1. The permission — what you are allowed to do: view stands, change configuration, run a build, create a release.
2. The scope — where you are allowed to do it: on a specific stand, on a project, on a cluster or across the whole system.

A permission granted on a wide scope applies to everything inside it: a permission on a cluster works on all of its projects and stands, a permission on a project works on all of its stands. The reverse is not true: a permission on one stand grants nothing on its neighbour.

Hence the classic situation: you can change the configuration on a test stand but not on a production one — the permission is the same, the scope is different.

What permissions typically unlock

What you can do	What it gives you
View stands	The stand is visible in the tree and its monitoring is available
View stand secrets	A separate permission: access to the configuration does not unlock secrets
View own builds / all builds	The build list shows only yours, or everyone's
View all processes	Workspaces started by other users

Three rules that explain the system's behaviour:

• There are no deny rules. Anything not granted is simply unavailable — nobody "forbids" a particular stand, it just was not granted to you.
• Permissions add up. You can receive them personally and through a group you belong to; the result is the union of everything granted.
• A write permission includes read. If you are allowed to change a stand's configuration, you can read it too.

Granting permissions, roles and groups is an administrator's job — an ordinary user's interface has none of those settings.

Why a button is disabled or missing

The interface does not show what would fail anyway. So "no permission" usually looks less like an error and more like a missing element:

• the button is not there — you lack the matching permission (“Deploy changes” or “New release”, for instance);
• the tab is not there — this is how the “Secrets” tab is hidden when you cannot read secrets;
• the section is not in the menu — none of the permissions it needs has been granted; if you open its address directly you are sent back to the home page;
• a stand "disappeared" from the tree — most likely you have no permission to view it, rather than it having been deleted;
• the cluster is visible but holds few stands — the permission was granted on individual stands, and the cluster is shown so that you can reach them;
• the list is empty — that does not always mean "there is nothing". An empty list can mean "not visible to you" rather than "no such data".

A hidden button is convenience, not protection

The server always makes the decision. Even if an element does show up for some reason, the operation will not run without the permission — you will get a refusal.

When permission changes take effect

Usually you do not have to sign in again. When an administrator changes your permissions, the application picks up the new set automatically within a short time, and open connections reconnect on their own.

If the interface still shows the old picture — a menu item has not appeared, a button is still missing — reload the page: the list of available permissions is re-read every time the application starts and right after sign-in.

Revoking works just as fast. Do not count on "it still works until the end of the day": as soon as a permission is removed, the action stops going through.

Something is missing — a checklist

Before going to an administrator, walk through four steps:

1. Reload the page. The most common cause is an application still running with the old set of permissions.
2. Check that it is the right stand. Stand names repeat across clusters — it is easy to be looking at a namesake from the cluster next door.
3. Try the same action on another stand. If the button is there, you do have the permission, but it was granted on a different scope.
4. Contact an administrator. Be specific: what you wanted to do, on which stand and in which cluster, and what exactly is not showing up.

A first sign-in does not grant permissions automatically

The account is created on first sign-in by itself, but it may start out with no permissions on any particular stand. An empty stand tree right after signing in is a normal starting point — permissions are granted by an administrator.

Permissions and AI agents

If you connected PDM to an AI agent, it acts strictly within your permissions — it has none of its own. Anything you cannot see, it cannot see either; a change to your permissions changes what it can do immediately.

See also

• Signing in — which account is used and what happens on a first sign-in.
• Active sessions — who and what has access to your account.
• Connecting an AI agent — an agent's access and its limits.