[finding] workspace owner lacks `manage_metadata` in the EE multi-org deploy, but 构建应用 is a primary home CTA — dead-ends at submit

[baozhoutao]

Recording an observation for the platform to rule on.

In the objectos-ee-deploy stack (multi-org, Postgres), the console home page offers 构建应用 / Build an app as one of its two primary calls to action. A workspace owner who follows it, fills in the new-package dialog and submits gets:

Managing packages requires the manage_metadata capability.

(also untranslated in a zh console — same family as #8094).

The owner's effective grants, from GET /api/v1/auth/me/permissions:

{
 "positions": ["org_owner", "everyone"],
 "permissionSets": ["organization_admin", "member_default"],
 "systemPermissions": ["manage_org_users", "setup.access", "setup.write"]
}

No manage_metadata. So on this deployment the person who created the workspace cannot create a package, an object, or an app — the entire "build" half of the product — while the button that starts that flow is the most prominent thing on their home page.

The decision

Plausibly deliberate: in a hosted multi-tenant deployment you may well not want tenants authoring metadata. If so, the fix is presentational — hide or disable 构建应用 (and 从模板开始, untested) when the capability is absent, and say why, rather than letting the user fill in a dialog and hit a raw capability error at submit time.

If it is not deliberate, organization_admin is missing a grant.

Either way the current combination — prominent CTA, full dialog, English capability error at the end — is the worst of both.

Environment

objectos-ee-deploy (Caddy → app → postgres:16) on http://localhost:8080, zh locale, org owner zhangsan@acme-test.com, observed 2026-08-12. Image commit not verified.

[baozhoutao]

Hit while trying to create a test object for the autonumber investigation in #8269. Same deployment as #8090–#8096.

[hotlong]

Triage: promoted finding → needs-user-decision; re-routed the self-made domain:access-security → domain:identity per the anchoring rule (every fix direction lands in the permission-set / capability surface; a presentational half would be a repo:objectui follow-up card once ruled). This is a permission-boundary product call — on the human floor, not auto-adjudicable.

The question: in the EE multi-org deploy, the workspace owner (org_owner position, organization_admin permission set) has no manage_metadata, so the home page's primary CTA (构建应用 / Build an app) dead-ends at submit with a raw English capability error. Is the posture deliberate (hosted tenants don't author metadata) or is organization_admin missing a grant?

Options:

• A. Grant manage_metadata to organization_admin — owners can build; matches the intent the home page advertises.
• B. Keep the posture; capability-gate the CTA (hide/disable + explain why) — fix is presentational, filed as a repo:objectui follow-up.
• C. Make it an explicit deployment-level posture switch — A and B become configurations of one declared key.

Four-prong:

• Platform long-term coherence: the current state is the worst shape — a capability the UI advertises and the backend refuses. Any of A/B/C shrinks the special case; C names the posture explicitly instead of deriving it from a grant's absence.
• Measured business pull: real, hit today — an org owner on the EE stack followed the primary home CTA into a dead end (found while setting up driver-sql: first concurrent autonumber insert from two tenants fails on Postgres (25P02) — the sequence-row race handler runs inside an already-aborted transaction #8269's investigation). The "build" half of the product is unreachable for the first persona every new workspace creates.
• AI-agent error-resistance: an explicit posture beats divergent per-surface behavior — today an agent reading the home page would conclude building is supported and generate dead-end flows; a declared switch (or a grant plus a capability-gated CTA) is checkable at authoring time.
• Startup scope discipline: B is the smallest change; C adds a permanent configuration key. If hosted multi-tenant authoring is not a near-term bet, B now (+ A/C later) is the cheapest honest state.

Recommendation: A if EE workspace owners are meant to build — the home page says they are — otherwise B. In either case the raw untranslated capability error at submit belongs to the #8094 family and should be fixed regardless of the ruling.

Related open decisions on the same deploy family: #8247 · #8240 · #8243.

---

Generated by Claude Code

[hotlong]

Maintainer ruling — hosted posture: no tenant metadata authoring; fix is presentational

Ruled by the maintainer in a live PM session, 2026-08-13 (session session_015XyMgCSMGGn9oSwbQEeWYg), verbatim:

EE 单库多租户下,workspace owner 不允许构建应用。

Ruling: the missing grant is intended — in the EE single-database multi-tenant deployment, workspace owners do not author metadata. organization_admin gains no manage_metadata; no permission change anywhere.

The remaining work is presentational, and it lands in objectui (hence the routing swap to repo:objectui):

• 构建应用 and 从模板开始 (and any other metadata-authoring CTA on the console home) are hidden or disabled when the session lacks the manage_metadata capability, with a visible reason — never a prominent CTA that dead-ends in a raw capability error after a filled-in dialog.
• The gate reads the capability the server already reports (GET /api/v1/auth/me/permissions) — ⛔ no client-side reimplementation of permission logic beyond consuming that answer.
• The refusal/explanation copy is localized (the measured error was untranslated English in a zh console — same family as console: organization & invitation UI ships untranslated English in a zh locale (6 sites, incl. icon-only aria-labels) #8094; fold the i18n fix for this message into the card).

Label swap: needs-user-decision + domain:identity → pm:queue + repo:objectui (fix lands entirely in the console; the objectstack-side question is settled by this ruling).

---

Generated by Claude Code