Summary
Two related gaps around list-view inline editing, observed on @objectstack/console@17.0.0 (stable):
- The list toolbar's inline-edit toggle (
toolbar-inline-edit-toggle) renders for every user, with no object update permission gate.
ListViewSchema.userActions.editInline (spec ui/view.zod.ts, boolean) is declared but consumed nowhere in console — so authors cannot even switch inline editing off wholesale.
Gap 1: no permission gate on the toggle
Render condition, verified in the console dist (plugins-views chunk):
viewType === 'grid' && onInlineEditChange callback present && !compactToolbar
…and the host passes onInlineEditChange unconditionally. There is no can(object, 'update') anywhere in this path. In the same component, the bulk-delete entry is gated with can(obj, 'delete') — inline edit is the one affordance on the toolbar without a permission check.
Consequence (tested with a read-only role)
An account without update permission on the object can:
- flip the toggle and enter inline-edit mode,
- modify cells,
- click Save all,
…and is only stopped by the server-side 403. No data lands (the server gate is solid — this is not a security issue), but the UI walks the user through a full editing round-trip that is guaranteed to fail. It is also inconsistent: on the very same toolbar, New and Import are correctly hidden for this account by permission — inline edit alone remains available.
Gap 2: userActions.editInline has zero consumers
Across the entire console dist, editInline appears only as an i18n label key. The spec-declared ListViewSchema.userActions.editInline boolean is never read — declared-but-inert metadata: a view author cannot disable inline editing even unconditionally.
Expected
- Gate the inline-edit toggle on
can(object, 'update'), aligned with the existing practice in the same bundle (record-detail showEdit, related-list edit affordances).
- Consume
userActions.editInline so the declared switch actually controls whether the toggle is offered.
Related (same family, different surfaces — all fixed)
Downstream tracking: steedos-labs/os-project-titanwind-ehr#1071 (private repo; covers gap 1).
Summary
Two related gaps around list-view inline editing, observed on
@objectstack/console@17.0.0(stable):toolbar-inline-edit-toggle) renders for every user, with no objectupdatepermission gate.ListViewSchema.userActions.editInline(specui/view.zod.ts, boolean) is declared but consumed nowhere in console — so authors cannot even switch inline editing off wholesale.Gap 1: no permission gate on the toggle
Render condition, verified in the console dist (plugins-views chunk):
…and the host passes
onInlineEditChangeunconditionally. There is nocan(object, 'update')anywhere in this path. In the same component, the bulk-delete entry is gated withcan(obj, 'delete')— inline edit is the one affordance on the toolbar without a permission check.Consequence (tested with a read-only role)
An account without
updatepermission on the object can:…and is only stopped by the server-side 403. No data lands (the server gate is solid — this is not a security issue), but the UI walks the user through a full editing round-trip that is guaranteed to fail. It is also inconsistent: on the very same toolbar, New and Import are correctly hidden for this account by permission — inline edit alone remains available.
Gap 2:
userActions.editInlinehas zero consumersAcross the entire console dist,
editInlineappears only as an i18n label key. The spec-declaredListViewSchema.userActions.editInlineboolean is never read — declared-but-inert metadata: a view author cannot disable inline editing even unconditionally.Expected
can(object, 'update'), aligned with the existing practice in the same bundle (record-detailshowEdit, related-list edit affordances).userActions.editInlineso the declared switch actually controls whether the toggle is offered.Related (same family, different surfaces — all fixed)
apiOperationsinstead of the caller's permission (fixed in PR fix(grid,list,app-shell): gate row Edit/Delete on the caller's permission, not just apiOperations #4108). Same "missing permission gate on one affordance while siblings have it" shape; this issue is the toolbar-inline-edit member.requiredPermissions.Downstream tracking: steedos-labs/os-project-titanwind-ehr#1071 (private repo; covers gap 1).