Skip to content

improvement(tables): show the lock chip only when a table is actually locked - #5967

Merged
TheodoreSpeaks merged 3 commits into
stagingfrom
improvement/table-lock-header-entry
Jul 25, 2026
Merged

improvement(tables): show the lock chip only when a table is actually locked#5967
TheodoreSpeaks merged 3 commits into
stagingfrom
improvement/table-lock-header-entry

Conversation

@TheodoreSpeaks

@TheodoreSpeaks TheodoreSpeaks commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator

Summary

  • Header chip only renders when a table is actually locked — it previously showed for any admin with the flag on, so unlocked tables permanently carried a "Lock settings" entry in the top right
  • Reaching the settings panel on an unlocked table is the breadcrumb dropdown's job; that entry already existed and is unchanged
  • Keep the "Append-only" name when the schema is locked too — append-only describes the row semantics, and a schema lock doesn't change them. The detail line calls out the locked columns instead

Follow-up to #5960.

Type of Change

  • Improvement

Testing

Tested manually. Lint, boundary validation, and the full audit suite pass; 513 table tests pass.

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

@TheodoreSpeaks
improvement(tables): show the lock chip only when a table is actually…
cfb4d2f 
… locked

- The header chip rendered whenever an admin had the flag on, so an unlocked
  table permanently carried a "Lock settings" entry. Header space is for
  state: the chip now appears only once something is locked and names the
  mode. The admin route to the panel on an unlocked table is the breadcrumb
  dropdown, which already had it
- Keep the Append-only name when the schema is locked too. Append-only
  describes the row semantics and a schema lock doesn't change them; the
  detail line calls out the locked columns instead
@vercel

vercel Bot commented Jul 25, 2026 •
edited
Loading

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Jul 25, 2026 9:39pm

Request Review

@cursor

cursor Bot commented Jul 25, 2026 •
edited
Loading

Copy link
Copy Markdown

PR Summary

Low Risk
Scoped feature-flag and UI entry-point changes; stored lock enforcement is unchanged and unlock-with-flag-off behavior is preserved.

Overview
Moves table-locks feature gating off NEXT_PUBLIC_TABLE_LOCKS and onto server-side isFeatureEnabled('table-locks') on the table page, using the workspace host org and viewer userId so org/user rollouts match the PATCH API. The table header lock chip only appears when something is actually locked (mode name); admins open lock settings from the breadcrumb dropdown on unlocked tables.

The PATCH route applies the same scoped flag check when enabling a lock (workspace org lookup only on that path). Lock updates now write richer audit entries (per-kind locked/unlocked text, before/after metadata, optional request for IP/UA).

Append-only labeling no longer requires schema to be unlocked; schema lock is mentioned in the detail line when present.

Reviewed by Cursor Bugbot for commit 0b72227. Bugbot is set up for automated code reviews on this repo. Configure here.

@greptile-apps

greptile-apps Bot commented Jul 25, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Greptile Summary

The PR limits the table-header lock chip to locked tables and aligns lock configuration, feature gating, labeling, and auditing across the UI and API.

  • Resolves the table-lock feature flag server-side using the workspace host organization and current user.
  • Keeps lock settings available through the breadcrumb dropdown while showing the header chip only for active locks.
  • Describes append-only row semantics accurately when the schema is also locked.
  • Records lock transitions with before/after state and request context in audit entries.

Confidence Score: 5/5

The PR appears safe to merge.

No blocking failure remains.

Important Files Changed
Filename Overview
apps/sim/app/api/table/[tableId]/route.ts Aligns the PATCH feature gate with the page’s user and workspace-host context before enabling locks.
apps/sim/app/workspace/[workspaceId]/tables/[tableId]/page.tsx Resolves the table-lock rollout server-side and supplies it to the client table component.
apps/sim/app/workspace/[workspaceId]/tables/[tableId]/table.tsx Shows the header lock chip only for active locks while retaining the gated breadcrumb settings entry.
apps/sim/app/workspace/[workspaceId]/tables/[tableId]/lock-copy.ts Preserves the append-only label when schema locking is additionally enabled and clarifies the detail text.
apps/sim/lib/table/service.ts Captures serialized before/after lock state and emits more descriptive audit metadata with request context.
apps/sim/lib/core/config/env.ts Removes the obsolete public environment mirror now that feature-flag resolution occurs server-side.

Reviews (2): Last reviewed commit: "fix(tables): resolve the lock flag with ..." | Re-trigger Greptile

@TheodoreSpeaks
improvement(tables): resolve the lock flag server-side and record loc…
f978389 
…k changes fully

- Drop NEXT_PUBLIC_TABLE_LOCKS. A feature flag's gating lives in AppConfig,
  which has no client counterpart, so mirroring it into a public env var meant
  AppConfig couldn't control the UI at all and org/user clauses could never
  reach the client — only global on/off. The page now resolves the flag with
  session context and passes it down, per the add-feature-flag skill. Embedded
  renders default to false, failing closed; enforcement of stored locks is
  unaffected either way
- Record the previous locks alongside the new ones and name the transitions in
  the audit description, so the log answers who locked what without expanding
  metadata. Forward the request for IP / user-agent capture
cursor[bot]
cursor Bot reviewed Jul 25, 2026
View reviewed changes
Comment thread apps/sim/app/api/table/[tableId]/route.ts
@TheodoreSpeaks
fix(tables): resolve the lock flag with the same context on both gates
0b72227 
The page passed userId/orgId while the PATCH gate resolved the flag with no
context, so an org- or user-targeted rollout would show the settings panel and
then 403 on save — the rollout path the previous commit exists to enable.

Both now key on the workspace's host organization rather than the viewer's
active one, matching the convention getWorkspaceHostContextForViewer
documents: active-org describes the account, not the workspace host. The
route's lookup runs only when a lock is actually being turned on.
@TheodoreSpeaks

TheodoreSpeaks commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator Author

@greptile

@TheodoreSpeaks

TheodoreSpeaks commented Jul 25, 2026

Copy link
Copy Markdown
Collaborator Author

@cursor review

cursor[bot]
cursor Bot reviewed Jul 25, 2026
View reviewed changes

@cursor cursor Bot left a comment

Copy link
Copy Markdown

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

✅ Bugbot reviewed your changes and found no new issues!

Comment @cursor review or bugbot run to trigger another review on this PR

Reviewed by Cursor Bugbot for commit 0b72227. Configure here.

@TheodoreSpeaks
TheodoreSpeaks merged commit 7f4cc38 into staging Jul 25, 2026
20 checks passed
@TheodoreSpeaks
TheodoreSpeaks deleted the improvement/table-lock-header-entry branch July 25, 2026 21:47
@waleedlatif1 waleedlatif1 mentioned this pull request Jul 26, 2026
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

@cursor cursor[bot] cursor[bot] left review comments

Assignees

No one assigned

Labels

None yet

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@TheodoreSpeaks