Skip to content

v17: retire the overloaded managedBy: 'system' bucket — move the 8 admin/user-writable objects to a dedicated bucket #3355

Description

@os-zhuang

Deferred breaking cleanup from the ADR-0103 addendum (v16 enum split, merged in #3352 / objectui#2739). Not urgent — this is a v17 major-only change.

Background

ADR-0103 (v16) split the overloaded managedBy: 'system' bucket additively: the 20 engine-owned objects moved to the new explicit engine-owned value, while the 8 admin/user-writable objects kept managedBy: 'system' — which now means "engine-managed schema, writable via userActions". That leaves system as a residual, still-overloaded value: its name says "system" but it now specifically labels writable platform DATA.

The addendum recorded the end state as a v17 change:

Removing the overloaded system entirely — moving the 8 writable objects to a dedicated writable-platform-data bucket (or config) and retiring system — is a genuinely breaking rename deferred to v17.

Scope — the 8 objects still on managedBy: 'system'

All declare userActions: { create: true, edit: true, delete: true } (or a subset). Authz is the DelegatedAdminGate / RLS / permission sets — the userActions is an affordance declaration only.

Object Home Kind
sys_user_preference platform-objects/identity User-owned preferences
sys_approval_delegation plugin-approvals Admin-authored delegation
sys_user_position plugin-security RBAC link table (DelegatedAdminGate)
sys_position_permission_set plugin-security RBAC link table
sys_user_permission_set plugin-security RBAC link table
sys_notification_subscription service-messaging Messaging config grid
sys_notification_template service-messaging Messaging config grid
sys_notification_preference service-messaging Messaging config grid

The design decision (resolve first)

What bucket do these move to? Two candidates:

  1. A new platform-data value — "platform-defined schema holding admin/user-writable data; authz via delegated administration / RLS." Cleanest fit; keeps them distinct from admin-authored config and from user-owned platform. The affordance default would be writable (create/edit/delete: true, so most drop their userActions), or stay locked-by-default with userActions — TBD.
  2. config — reuse the existing admin-authored bucket. Simpler (no new value) but semantically loose: several of these are user-owned (sys_user_preference) or governed by delegated admin / RLS, not "admin authored," and config suppresses CSV import which some may want.

Recommend option 1 (a dedicated value) unless the affordance semantics of config prove an exact match.

Blast radius (mirrors the v16 split)

  • framework — spec enum + CRUD_AFFORDANCE_DEFAULTS (packages/spec/src/data/object.zod.ts); remove 'system' and its default row; guard sets (ENGINE_OWNED_BUCKETS, GUARDED_WRITE_BUCKETS) if the new bucket needs listing; the 8 object declarations; tests; ADR update; objects.mdx + regenerated references.
  • objectuiManagedByBucket union + MANAGED_BY_BUCKETS (@object-ui/types); resolveCrudAffordances DEFAULTS (@object-ui/core); ManagedByBadge variant + resolveManagedByEmptyState (@object-ui/app-shell).

Why v17 (breaking)

  • Removes an enum value (system) — any downstream app or package declaring managedBy: 'system' becomes invalid (a type error against the closed union, and unknown at runtime → platform fallthrough).
  • Unlike the v16 addition, this is not additive: it changes the meaning of existing declarations.

Not in scope / already handled

  • Enforcement is unaffected either way — resolveCrudAffordances + the engine write guard drive the policy off resolved affordances, not the bucket literal (verified: no code branches on === 'system'). This is purely a taxonomy/self-documentation cleanup.
  • The v16 engine-owned split, dogfood verification, and the userActions de-dup are done (feat(spec): explicit engine-owned managedBy bucket (ADR-0103 addendum, #3343) #3352, objectui#2739, objectui#2724).

Related

#3343 (parent tracking issue) · #3352 · objectui#2739 · objectui#2724 · ADR-0103 (+ its v16 addendum)

Metadata

Metadata

Assignees

No one assigned

    Labels

    enhancementNew feature or request

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions