Repository navigation
fix: column layout does not follow the user - #949
Merged
Merged
Conversation
Column visibility and order lived in localStorage, so the same account on another computer got the defaults.
A shared browser was treating the previous person's columns as this account's. Read-only tokens can no longer write the saved row.
Paint this user's saved columns before the network read returns, and move a pre-account browser layout onto that user instead of dropping it.
An empty account row is not a reset. Drop the browser copy only after a layout this browser already saved is gone from the account.
The account row is shared, so the revision is per table. A lost save paints the account layout instead of keeping the edit that did not land.
An insert conflict on another table merges this one instead of returning 409. A pre-account layout stays on this browser until the next column change.
A 409 drops writes queued behind it, so the account layout that was just painted is not overwritten. The pre-account owner is per table.
A 409 paints a normalized layout, and a successful reset clears the revision so the next edit is not treated as a delete from another computer.
The write queue kept the transport from the first request, so a save queued after remount painted through the unmounted table.
A 409 that finishes after remount was applied to the instance that started the save, so the visible table kept the layout the account rejected.
A hydrate that starts while a save is in flight, or that returns an older revision, no longer overwrites the edit this browser already made.
An older account revision was treated as a stale read, so a backup restore never painted. That skip now applies only to a read that started during this browser's save.
A read that starts during a write and returns after it finishes was only dropped when the revision was older. An empty first-save read and a reset read that still had the old revision painted over the write.
A stale read is dropped when the stored revision changes during it, including a write from another tab. Switching accounts paints that account's layout or the defaults, not the previous user's columns.
A 409 paints only the table still mounted for that user. A read also leaves a layout another tab wrote before its save returned.
A save leaves a short-lived marker so a read in another tab does not cache the old account row over it. A queued save is dropped when the signed-in user changes, and it is not resent as the new user.
The save marker stays while a later write is queued. Unmount drops writes that have not started, and a hydrate that finishes after unmount does not enqueue one.
The write names the user who queued it. The server rejects that write if the session is now someone else, and the save marker stays up while a later save is still queued.
A 403 on reset was clearing the marker, so the old layout came back. The marker stays so the reset is retried for that user.
A 401 was treated like a rejected write and cleared the retry marker. The edit or reset stays for that user, and a user change no longer drops their queued save.
A 401 or 403 on reset was discarding the later edit without marking it unsynced. That edit now runs and keeps its retry marker.
The table paints the last owner's cache while the session is pending, and an edit made in that window is saved once the user id is known.
An edit or reset made before the user id is known is saved for the account that arrives. The table shows defaults until then, so a shared browser does not flash the first account's columns.
The table returns to defaults when the user id is gone, so the next account does not inherit that edit. A stored layout the client was never shown can be replaced or deleted. A later reset is sent again.
That click is not this account's edit of their saved columns, and it is not the next account's either. The table shows defaults until the user id arrives, then that account's own layout.
Hydration was clearing that revision before the delete was sent, so the server rejected the retry and the reset was undone.
The read refuses a different signed-in user, and the browser does not cache a reply that is not this account.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Column visibility and order lived in localStorage, so the same account on another computer got the defaults. Issue 941.
They are now one JSON row per user in user_table_layouts. The table still paints from localStorage, then applies the account row. A layout that exists only in this browser is uploaded when the account has no copy of that table. Reset deletes that table's saved row. Saving one table does not replace another. Theme and favorites stay in the browser.
Tests: pytest backend/tests/test_table_layouts.py (12 passed), npx tsx --test frontend/src/lib/table-layout.test.ts (9 passed), npx tsc --noEmit, npm run lint.
Closes #941