Tags: bytebase/bytebase
Tags
test(e2e): add schema editor e2e coverage (BYT-9802) (#20725) * test(e2e): add schema editor e2e coverage (BYT-9802) Add end-to-end Playwright coverage for the React Schema editor (SchemaEditorLite), reached from a plan's Statement section. BYT-9802's two reported symptoms (backspace in the table/column name inputs and column-type dropdown selection) are fixed on main and are now locked by passing regression tests. Specs (frontend/tests/e2e/schema-editor/, 20 CUJ tests + 1 bug-lock): - create-table: default id PK, backspace in name (BYT-9802), duplicate validation, cancel - columns: add column, type dropdown select (BYT-9802), backspace in column name (BYT-9802), custom free-text type, PK-forces-not-null, PK disabled on existing tables, drop/restore columns, default value - tree-nav: object navigation, drop table -> DROP TABLE - diff-insert: full create -> Insert SQL, no-diff notice, maximize - objects: create schema + duplicate validation Includes a test.fail bug-lock for BYT-9806: on a newly-created table the DDL preview does not refresh on column edits, because refreshTableEditStatus short-circuits for created tables (refreshEditStatus.ts:95) so editStatus.version never bumps and PreviewPane's memo never recomputes. Grid + inserted SQL are correct. Also: global-setup now tears down a half-started server when the boot throws. Playwright skips globalTeardown on a globalSetup failure, so a failed/slow boot previously orphaned the server process group + temp dir and starved subsequent boots. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(mssql): resolve encrypted/unparseable view columns from synced me… …tadata (BYT-9720) (#20625) * fix(mssql): resolve encrypted/unparseable view columns from synced metadata (BYT-9720) A SQL Server view created `WITH ENCRYPTION` exposes no retrievable body; sync stores a placeholder comment instead of DDL. The TSQL query-span extractor parsed that comment, found no `CREATE VIEW`, and hard-errored ("no CREATE VIEW statement found in definition"), which blocked column fetch and any query referencing the view in the SQL Editor. Fall back to the already-synced column metadata (populated from `sys.columns` regardless of encryption) when a view definition has no parseable `CREATE VIEW`. Each column is attributed to the view's own column. Genuine ResourceNotFoundError and parse failures on a real `CREATE VIEW` body still propagate, preserving the auto-resync flow and the masking-integrity signal. Trade-off: lineage to base tables is unrecoverable for an encrypted view, so data queried through one is returned UNMASKED — base-table masking cannot be traced through a hidden body. Scoped narrowly to definitions that are not a parseable CREATE VIEW; normal views are unaffected. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(mssql): full-mask unknown-lineage view columns instead of failing open (BYT-9720) Addresses P1 review feedback. The previous fallback attributed each encrypted-view result column to the view itself, but the result masker resolves catalog entries via base tables only (SchemaMetadata.GetTable), so those view-column resources matched no policy and returned a NoneMasker — turning the prior hard error into sensitive data served unmasked. Flag fallback columns with QuerySpanResult.UnknownLineage instead, and fully mask them in the result masker (and redact errors that reference them). Lineage to base tables is unrecoverable for an encrypted view, so we fail safe: browsing and queries keep working while data a base-table masking policy would protect is never leaked. A DBA can classify the view's columns to refine masking later. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(mssql): propagate unknown-lineage taint through expressions and fail closed on empty columns (BYT-9720) Address P1/P2 review feedback on the masking fail-safe. P1: a per-result UnknownLineage bool was dropped whenever expression or subquery sources were merged (e.g. `secret + 'x'` over an encrypted column), so the result reached the masker untainted and was returned unmasked. Move the taint onto the source ColumnResource instead; because source-column sets are unioned on every merge, it now propagates through expressions and subqueries automatically, with no per-merge-site changes. P2: an encrypted view with no synced columns produced an empty result span, so `SELECT *` returned actual columns the masker never masked. Fail closed in that case — with neither a parseable body nor a synced shape, the result cannot be resolved safely. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(mssql): mask unknown-lineage columns at the resolver so predicates are covered (BYT-9720) Address P2 review feedback. spanTouchesMaskedColumns only inspected result sources, so a predicate-only encrypted-view column (e.g. WHERE CAST(secret AS int) = 0) was not treated as masked, and a value-bearing database error could be returned unredacted. Move the unknown-lineage check into getMaskerForColumnResource — the single resolver every masking path routes through — instead of guarding each caller. getMaskersForQuerySpan (result masking) and spanTouchesMaskedColumns (error redaction over results and predicates alike) both honor the taint now, and the two caller-side early-returns plus the helper are removed. Added a parser test that a `WHERE secret = ...` predicate over an encrypted view stays tainted. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(mssql): treat unknown-lineage predicate columns as sensitive (BYT-9720) Address P1 review feedback. ExtractSensitivePredicateColumns guards against inference leaks through sensitive predicates — e.g. `SELECT COUNT(*) FROM enc_vw WHERE secret = 'x'` reveals row counts even though nothing sensitive is projected — but it resolved predicate columns via data.getColumn, which skips view columns, so an encrypted view's predicate column was never flagged. Treat UnknownLineage predicate columns as sensitive in getSensitiveColumnsForPredicate, so such queries are blocked rather than leaking through aggregate/existence projections. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> * fix(mssql): carry unknown-lineage taint through SELECT ... INTO temp tables (BYT-9720) Address P1 review feedback. `SELECT secret INTO #tmp FROM enc_vw` materialized the encrypted column into a temp table, but temp-table metadata kept only column names, so a later `SELECT ... FROM #tmp` resolved to the temp table (not a base table) and the masker returned it unmasked. Add UnknownLineage to base.PhysicalTable, set it when SELECT ... INTO sources at least one unknown-lineage column, and propagate it through PhysicalTable.GetQuerySpanResult so columns read back from the temp table stay tainted and fully masked. Both temp-table reference paths (#tmp and @t) are covered. The broader loss of column-level lineage through temp tables is a pre-existing, general limitation; this carries a conservative table-level taint for the encrypted-view case. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com> --------- Co-authored-by: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
fix(react): keep labels next to truncated title in issue/project rows (… …#20291) Removes flex-1 from the title element wrapping EllipsisText in the My Issues row and the Projects table name cell. flex-1 made the title consume all available space, pushing sibling labels and the archived badge to the far edge instead of sitting next to the title. With just min-w-0, the title sizes to its content and still shrinks/truncates when the row overflows. Co-authored-by: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
feat(pg): add metadata schema diff migration (#20098) (#20100) * feat(pg): add metadata schema diff migration * fix(pg): handle metadata diff dependency edge cases * fix(pg): handle metadata diff dependent objects * fix(pg): order metadata diff table dependencies (cherry picked from commit 596acb6) Co-authored-by: rebelice <yangrebelice@gmail.com>
refactor(frontend): remove Vue bridges from project database detail (#… …19924) * docs: add database detail react migration design * refactor(frontend): migrate database overview panel to react * test(frontend): remove vue scaffolding from overview panel test * fix(frontend): restore overview legacy behavior * fix(frontend): restore overview panel parity * fix(frontend): restore overview panel query and loading parity * refactor(frontend): migrate database history panels to react * refactor(frontend): migrate database catalog panel to react * refactor(frontend): remove database detail vue bridges * test(frontend): align database detail page test after rebase * docs: add locale sorter design * feat(frontend): add locale sorter script * fix(frontend): avoid partial locale sorting writes * fix(frontend): rollback failed locale sort writes * fix(frontend): restore current file on sort rollback * chore(frontend): run locale sorting during fix * chore(frontend): validate locale sorting in check * fix(frontend): address database detail review feedback * docs: add revision import parity design * fix(frontend): restore inline catalog retagging * fix(frontend): restore database detail overview table
fix(frontend): fix webhook detail page broken by UUID resource_id mig… …ration (#19719) (#19720) The migration from integer IDs to UUID resource_ids (migration 3.16.3) broke the webhook detail page. The slug format "title-UUID" was parsed by splitting on "-" and taking the last segment, which only returned the last UUID segment instead of the full UUID. This caused the webhook lookup to fail, falling back to an empty default webhook, which then caused "invalid request" errors on update. Replace slug-based routing with direct resource_id routing: - Route param changed from :projectWebhookSlug to :webhookResourceId - Navigate with extractProjectWebhookID() instead of projectWebhookV1Slug() - Compare webhook IDs as strings instead of parseInt() - Remove dead code: idFromSlug, projectWebhookV1Slug (cherry picked from commit f69a9d6) Co-authored-by: Vincent Huang <40749774+vsai12@users.noreply.github.com> Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
fix(frontend): make project table responsive with horizontal scroll (#… …19601) Add responsive behavior to the project table: use element width detection to hide extended columns on smaller screens, set scroll-x based on column widths, and use minWidth for flexible column sizing. Co-authored-by: Claude Opus 4.6 <noreply@anthropic.com>
PreviousNext