[asaah262]

Description

Keep the short labels of the built-in unified roles in one place, the unifiedrole package, and use them in both the CLI and the theme defaults of the web service:

• Labels: add unifiedrole.GetUnifiedRoleLabel(id), which returns the label of a built-in role, or an empty string for an unknown ID. The values are the ones graph list-unified-roles already printed, e.g. Viewer, SpaceManager and Denied.
• CLI: graph list-unified-roles uses the shared labels. Its first column is now called Label instead of Name; the values don't change.
• Theme defaults: every common.shareRoles entry now has a label with the same value as the CLI. Before, the entries used values like UnifiedRoleViewer, UnifiedRoleSecureView or UnifiedRoleUploader, and the three viewer roles used a name key instead of label.
• Built-in theme: the OpenCloud theme.json no longer sets the labels itself, so it can't override them with other values. It only sets the icons.
• Docs: the root and the graph README describe the Label column.

Icons don't change, and the web client only reads iconName from common.shareRoles, so the UI is unaffected.

Related Issue

• Related: web: four share roles have no icon in the theme defaults #3991 (four share roles have no icon in the theme defaults; not part of this PR)

Motivation and Context

The labels were defined twice, with different values: in the CLI command, and in the theme defaults and the built-in theme.json. The theme also used two different keys for them. A role could be added without a label, and the two places could drift apart.

How Has This Been Tested?

• Test environment: macOS, Go, local development worktree.
• New and updated unit tests:
  • GetUnifiedRoleLabel returns the expected labels, and an empty string for an empty or unknown ID.
  • Every built-in role has a non-empty, unique label, so a new role can't be added without one.
  • The theme defaults carry the label under label and have no name key.
  • The served built-in OpenCloud theme carries exactly these labels for every share role.
• go test -race ./services/graph/... ./services/web/... passes in all packages.
• go build ./..., go vet on the changed packages, gofmt and git diff --check are clean.
• Ran opencloud graph list-unified-roles locally: the Label column shows a label for all 21 roles.
• Not run locally: the acceptance test cliCommands/graphListUnifiedRoles.feature. The strings it expects are still in the output; CI will run it.

Screenshots (if appropriate):

Not applicable.

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation added

AI assistance: Claude Code (claude-opus-5-5) wrote the first draft of the code and the tests.

[codacy-production]

Up to standards ✅

🟢 Issues 0 issues

Results:
0 new issues

View in Codacy

🟢 Metrics 6 complexity

Metric	Results
Complexity	6

View in Codacy

🟢 Coverage 60.00% diff coverage · +0.02% coverage variation

Metric	Results
Coverage variation	✅ +0.02% coverage variation (-1.00%)
Diff coverage	✅ 60.00% diff coverage

View coverage diff in Codacy

Coverage variation details

	Coverable lines	Covered lines	Coverage
Common ancestor commit (f3810e8)	94086	27848	29.60%
Head commit (f815a94)	94089 (+3)	27866 (+18)	29.62% (+0.02%)

Coverage variation is the difference between the coverage for the head and common ancestor commits of the pull request branch: <coverage of head commit> - <coverage of common ancestor commit>

Diff coverage details

	Coverable lines	Covered lines	Diff coverage
Pull request (#3992)	5	3	60.00%

Diff coverage is the percentage of lines that are covered by tests out of the coverable lines that the pull request added or modified: <covered lines added or modified>/<coverable lines added or modified> * 100%

_{NEW Get contextual insights on your PRs based on Codacy's metrics, along with PR and Jira context, without leaving GitHub. Enable AI reviewer
TIP This summary will be updated as you push new changes.}

[pbleser-oc]

Looks good, thanks. The labels now live in one place, and the tests make sure a new role can't be added without one, or with a label that is already taken.

What I checked:

• The web client only reads iconName from common.shareRoles (the theme schema in packages/web-pkg/src/composables/piniaStores/theme.ts has no other field), so the changed label values and the removed name key don't affect the UI.
• cliCommands/graphListUnifiedRoles.feature only checks that the command succeeds, so the new Label header doesn't break it, and the CI is green.
• The labels are the ones the CLI already printed (e.g. SpaceManager), so its output only changes in the header. Removing the labels from the built-in theme.json means it can't override the shared ones any more. The new theme test would catch it if they came back.
• Locally, the build, go vet and go test -race pass for services/graph/pkg/unifiedrole, services/graph/pkg/command and services/web/....

The four roles without an icon are tracked in #3991, so it's fine that they're not part of this PR.