Repository navigation
Implemented auto backup - #11
Merged
Merged
Conversation
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
Deploying with
|
| Latest commit: |
8fd9421
|
| Status: | ✅ Deploy successful! |
| Preview URL: | https://2dde8eae.immich.pages.dev |
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
2 of 3 tasks
1 task
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
1 of 3 tasks
2 of 4 tasks
2 of 4 tasks
2 of 4 tasks
2 of 4 tasks
2 of 4 tasks
2 of 4 tasks
3 of 4 tasks
2 of 4 tasks
3 of 4 tasks
2 of 4 tasks
1 of 4 tasks
2 of 4 tasks
2 of 4 tasks
3 of 4 tasks
2 of 4 tasks
Closed
1 of 4 tasks
2 of 4 tasks
azamiftikhar1000
pushed a commit
to inhotel-io/inreveal-immich-archive
that referenced
this pull request
Aug 26, 2026
…mmich-app#11/immich-app#13) Fork PR immich-app#683 persisted the People-page sort as legacy Isar `StoreKey` int ordinal 1015. This rolling branch adopted upstream's v3 Drift `SettingsKey`/settings_entity architecture (immich-app#28691) and the People sort was ported to `SettingsKey.peopleSortBy`, but no migration entry moved an existing legacy value across -- so any user who had set a sort before upgrading silently lost it back to the default. Add `StoreKey.legacyPeopleSortBy` (id 1015, matching main's original id) and wire it through the existing `_StoreMigrator.migrateEnumIndex` helper in `_migrateTo26`, the same pattern already used for the other five enum-ordinal legacy settings. `_migrateTo26`'s targetVersion (26) has never shipped to users on this branch (the SettingsKey architecture commit is not an ancestor of `main`), so no new migration version is needed -- every upgrader runs the fixed `_migrateTo26` for the first time. Covers: legacy ordinal present -> migrated; no legacy value -> default preserved; out-of-range ordinal -> no crash, left un-migrated (matches existing generic migrateEnumIndex behavior); idempotent re-run; fresh install untouched.
azamiftikhar1000
pushed a commit
to inhotel-io/inreveal-immich-archive
that referenced
this pull request
Aug 26, 2026
…ch-app#713) (immich-app#715) * docs(timeline): design for immich-app#713 All-view height-cap fix * docs(timeline): tighten immich-app#713 spec after self-review - deterministic test for scroll-stability invariant (was state-machine dependent) - coverage-boundary section + required component test for renderOffset template wiring - add edge cases: live asset insert, DOM scrollTop integer rounding - note clamp already imported; tidy fake test element * docs(timeline): inline Firefox cap check to avoid circular import (immich-app#713) * docs(timeline): TDD implementation plan for immich-app#713 height-cap fix * docs(timeline): tighten immich-app#713 impl plan after review - add zero-viewport guard test (edge immich-app#6) and scrollTo(0)/negative clamp (edge immich-app#11) - clarify Task 2 red phase: test 9 is a scale-1 regression guard, not a red driver - make translate3d component assertions normalization-robust (regex vs raw style) - per-edge-case coverage map; mark edges 7 (browser cap) and 16 (limitedScroll) not-unit-tested-by-design * feat(web): scroll-space scaling engine in VirtualScrollManager (immich-app#713) * feat(web): map timeline scroll between logical and capped DOM space (immich-app#713) * feat(web): render timeline content in capped DOM space via renderOffset (immich-app#713) * fix(web): offset timeline lead-in section by renderOffset (immich-app#713) The top/lead-in section rendered at DOM y=0 while months, representative buckets and the lead-out spacer all render at `top + renderOffset`. On an above-cap library (renderOffset != 0), the first month was drawn over the still-visible lead-in when scrolling down from the top. Shift the top section by renderOffset too so it stays in the same capped coordinate space. Below the cap renderOffset is 0, so behaviour is unchanged. Adds a regression test asserting the top section transform tracks renderOffset (found in review of the immich-app#713 height-cap change). * fix(web): re-derive scroll mapping on timeline geometry change (immich-app#713) The cached DOM<->logical scroll mapping (#scrollTop / #cachedDomScrollTop, and therefore renderOffset) was only refreshed in updateSlidingWindow, i.e. on scroll events. A viewport resize or width reflow changes the scale (domScrollMax / logicalScrollMax) without a scroll event, leaving the cache computed against the old scale — so the next scroll teleported the timeline by the accumulated drift on very large above-cap libraries. Add resyncScrollMapping() (skips updateSlidingWindow's change guard, since the DOM scrollTop can be unchanged while the scale is not) and call it from updateViewportGeometry after the geometry recompute, before proximities. Adds a regression test asserting renderOffset stays consistent with the DOM scrollTop across a viewport resize (found in review of immich-app#713). * fix(web): scale the timeline scroll cap by devicePixelRatio (immich-app#713) The browser's element-height ceiling is expressed in device pixels, but the cap was a flat CSS-pixel constant. On a HiDPI display each CSS pixel spends `devicePixelRatio` of that budget, so the 33,000,000px request asked for 66,000,000 device pixels on a 2x screen. The browser silently clamped the element to 16,777,214px (2^25 / 2) while `domScrollMax` kept being derived from the requested 33,000,000 — so `domToLogical` divided by a scroll range that did not exist and the tail of the timeline became unreachable. Measured on a 750k-asset library at dpr 2: scrollTop maxed out at 16,776,443 of a believed 32,999,059, stranding the timeline at ~50.8% of the library (mid-2023) with no way to scroll further. At dpr 1 nothing clamps, which is why this never reproduced on a non-Retina display. Derive the budget from the device-pixel ceiling divided by dpr, and re-derive it on viewport geometry changes so moving the window between displays of different density does not silently reintroduce the clamp. * fix(web): cap timeline scroll at Firefox's scrollable range, not its layout ceiling (immich-app#713) Firefox lays out an element up to nscoord_MAX (17,895,697px) but only allows scrolling half of it. Measured on a 750k-asset library at dpr 1: a 17,537,784px element reported scrollHeight 8,947,850 and refused to scroll past 8,946,658, so domScrollMax was ~2x the range the browser actually grants and domToLogical stranded the timeline at ~51% of the library. Unlike the Chromium case this is not a devicePixelRatio problem — it reproduced at dpr 1. Split the engine ceilings apart and use nscoord_MAX/2 for Firefox.
deepakjoshisyfe
added a commit
to deepakjoshiss/immich
that referenced
this pull request
Sep 8, 2026
Owner's call: the vault holds tens of files, so scanning the directory is always correct by construction and an index would be a second source of truth to keep in sync. DECISIONS.md immich-app#11 records when that stops being true. Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
2 of 4 tasks
2 of 4 tasks
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.
Auto backup is now working.
Auto backup run when