Authorize and manage Project labels in the Console

Assigning a Label to a Project is a privileged act: a Domain admin does not automatically get to assign Labels. Each assignment needs two explicit relations the admin relation does not confer — maintainer on the Project and assigner on the Label definition. The Label workbench tool in the Console writes both for you in one click and co-locates the assignment work that grant unblocks, so you no longer compose project:<id> and labeldefinition:<id> references by hand across three surfaces.

This guide is the Console counterpart of the plexctl-driven Assign labels to objects guide and the Label your first Project tutorial.

Prerequisites

• An authenticated Console session.
• Domain admin on the Project's Domain — the manage permission on the Project is what authorizes writing the two relations.
• At least one Label definition in scope that applies to a Project — see Manage Label Definitions.

Steps

Pick a Project

Open Tools → Label workbench. Select a Domain in the top-bar switcher if you have not already; the picker lists the Projects in that Domain you can read. Choose the Project you want to work on. If you are not a member of any Project in the Domain, the picker says so rather than showing an empty control.

Authorize yourself in one click

In the Authorize me to assign here panel, the subject defaults to your own user. Pick the Label definition you intend to assign, then click Authorize me to assign here. One action writes both grants:

• maintainer on the selected Project, and
• assigner on the selected definition.

The resource references are derived from your selection — you never type project:<id> or labeldefinition:<id>. To authorize a teammate instead, replace the subject with their user:<id> (or a group:<id>#member) before clicking.

The action is safe to run again. If only one of the two grants lands, the panel says which one succeeded and leaves it in place, so re-running finishes the job. If you lack manage on the Project, the panel tells you that you need Domain admin to grant these relations rather than failing silently.

Manage the Project's definitions

The Label definitions in scope section lists the definitions visible at the Project's scope. Use a row's Remove action to delete a definition from the Project. A definition that still has assignments under the block policy, or a system-managed definition, cannot be removed — the workbench shows a clear inline message in that case.

Assign and detach labels

The Labels section lists the Labels currently on the Project. Use Assign Label to attach a definition and value, and a row's Detach to remove one. The server validates the value against the definition's schema, so a value the schema rejects surfaces inline.

When a grant has not propagated yet

Grants take a moment to reach the authorization backend, so the first assignment right after authorizing can be denied. The workbench shows this as a friendly "the grant is still propagating — wait a moment and try the assignment again" hint rather than a hard error. Wait a couple of seconds and retry the assignment.

Why authorization is a separate step

The workbench makes the grant ergonomic; it does not weaken the security boundary. The two relations are still written explicitly and are still authorized by manage on the Project. Administering a Domain never silently confers the right to attach Labels to things, so a tag can never quietly escalate access.