The myRole select added for issue #286 wasn't included in the GROUP BY
clause, causing a 500 ("column album_user.role must appear in the
GROUP BY clause") whenever includeShared=true was requested.
Closes#286. The album picker for add_to_album/remove_from_album only
showed albums owned by the current user. Add an opt-in ?includeShared
param to /api/albums/list that also includes albums where the user
has 'editor' role (upload access), and group the picker into 'My
Albums' / 'Shared Albums' sections. Other callers of listAlbums()
don't pass includeShared, so they keep the existing owner-only
behavior unchanged.
Merges potential-trips + potential-trip-assets into
potential-albums-dates + potential-albums-assets respectively, keyed
by a new ?groupBy=day|trip query param. The actual grouping logic is
extracted into two new helper files (potentialAlbumsGrouping.helper.ts,
potentialAlbumsAssets.helper.ts), each holding a day-mode and
trip-mode function the unified handlers call into.
Client-facing functions (listPotentialTrips, listPotentialTripAssets)
keep their existing names/signatures — only their internal path and a
groupBy param changed — so no frontend component call sites need
updating. Also drops the two now-unused LIST_POTENTIAL_TRIP*_PATH
route constants.
Addresses the maintainer's open caching-strategy question by removing
the need for a second endpoint/cache entirely: one endpoint per
concern, two grouping strategies.
Immich v3 dropped asset.deviceId/deviceAssetId (af4cfce on main).
This branch predates that migration, so its own SELECT_ORPHAN_RANGE
query still referenced the column, which would 500 on any current
Immich v3 instance. Match the field list already used by the sibling
potential-albums-assets.ts endpoint, which was updated for v3.
clusterTrips's gap check compared array-index adjacency between
DaySignal entries. Since `days` only contains dates with >=1 photo
(GROUP BY DATE(...) with no zero-photo rows), two trips separated by
months with no photos in between were array-adjacent (gapLen=0) and
got merged into one bogus trip. Compare actual elapsed calendar days
between the last and next away day instead.
The local tag table can lag behind Immich's own tag state (e.g. tags
created directly in Immich, or before this app's sync ran), causing
remove_tag to silently no-op on a tag that actually exists. Mirror the
sibling "tag" action's approach and resolve against the Immich API,
matching on the tag's full-path "value" field. Drops the now-unused
db/sql local lookup.
makeDeviceAssetId(item.assetId) was passed as an extra 5th argument
before tagId, which doesn't match uploadAssetBuffer's signature
(asset, payload, uploadHeaders, jsonHeaders, tagId?) and broke the
TS build. Match the call pattern used by the sibling nextcloud/immich
processors.
The id list was built via raw string interpolation into sql.raw().
Switch to sql.join with proper parameter binding, matching the
pattern used by the other match branches in this function.
Removes a tag (by name, matching the tag's full path value) from the
matched assets via DELETE /tags/:id/assets. The tag is looked up
without creating it — removing a tag that doesn't exist is a no-op
rather than an error, so add/remove pairs are safe in the same
workflow.
Registered in the node palette, action node, run-detail view, and
action config (same tag-name field as Add Tag).
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds condition types common in smart-album systems of other photo
managers (Apple Photos, Lightroom, Google Photos):
- File Size: min/max in MB (fractional) over asset_exif.fileSizeInByte
- File Name / Path: contains / not contains / starts with / ends with
against originalFileName or originalPath (ILIKE, wildcards escaped so
user text matches literally)
- File Extension: is any of / is none of a comma-separated list,
case-insensitive, matched after the last dot
- Face Count: min/max visible, non-deleted detected faces — 'how many
people', complementing the person condition's 'who'
- Time of Day: from/to hour over localDateTime (capture wall-clock
time, no timezone math); From > To wraps past midnight (22 to 5)
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds a "Resolution" condition type filtering assets by image
dimensions, useful for isolating low-resolution images for cleanup or
selecting high-resolution ones.
Three metrics with optional min/max bounds:
- Megapixels (width x height / 1e6, fractional values allowed)
- Short edge in pixels (LEAST of width/height)
- Long edge in pixels (GREATEST of width/height)
Short/long edge are orientation-agnostic, so a 4000x3000 landscape and
a 3000x4000 portrait are treated identically. Uses the exifImageWidth/
exifImageHeight columns on asset_exif, which the condition queries
already join; assets without recorded dimensions never match.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Adds a "Tag" condition type that filters assets by Immich tags, with
the same match modes as the person condition (has any of / has all of /
has none of). Selected tags also match their child tags via Immich's
tag_closure hierarchy table, mirroring how tag browsing behaves in
Immich itself.
- conditionBuilder: tag case with EXISTS subqueries on tag_asset,
descendant-inclusive via tag_closure (plus a direct id check so a
missing self-closure row can't drop matches)
- ConditionEditor: Tag entry + TagPicker multi-select (PersonPicker
pattern) with tag color chips
- conditionSummary: node label ("Tag any of: ...")
- new GET /api/tags route + client handler + drizzle schema for
Immich's tag table
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
All workflow trigger queries were capped at .limit(10000) with no
ORDER BY and no pagination, so on libraries larger than 10k assets an
all_assets ("full library scan") trigger silently evaluated an
arbitrary 10k subset. The IF/SWITCH condition queries had the same cap,
and bulk actions sent every asset id in a single Immich API request.
- resolveAssetTrigger: keyset pagination (ORDER BY id, batches of 5000)
for all three trigger types
- IF/SWITCH: evaluate conditions against the incoming asset set in
chunks instead of one capped inArray query
- actionExecutor: call Immich bulk endpoints in batches of 1000 ids
Verified on a 26,063-asset library (Immich v3.0.1): all_assets now
resolves 26,063 (previously 10,000), a person-filter IF matched 813
assets vs 142 under the cap, and a 25,250-asset remove_from_album
branch completed via batched requests.
Fixes#296.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
Immich v3 split album-membership rights out of album.update into
albumAsset.create / albumAsset.delete, and assigning tags to assets
requires tag.asset. The hardcoded WORKFLOW_PERMISSIONS list predates
this, so auto-generated workflow keys 403 at runtime on Add to Album
(and Add Tag) actions:
Immich API error 403: {"message":"Missing required permission: albumAsset.create"}
Also, validate-api-key.ts literal-matched required permissions against
the key's permission list, so a key created with the "All" checkbox
(stored as ["all"]) failed validation for every permission — and the
settings page refuses to save a key that fails validation, making it
impossible to work around with a full-permission key.
- Add albumAsset.create, albumAsset.delete, tag.asset to
WORKFLOW_PERMISSIONS (matching the endpoints actionExecutor.ts
actually calls: PUT/DELETE /albums/:id/assets, PUT /tags/:id/assets)
- Add albumAsset.create to IMPORT_PERMISSIONS for the same reason
- Treat a granted "all" permission as satisfying all requirements in
validate-api-key.ts
Follow-up to #294.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
- Updated albumColumns and AlbumThumbnail components to display placeholder when no thumbnail is available.
- added album_user table (album ownership moved here, role='owner')
- drop asset.deviceId/deviceAssetId and albums.ownerId
- asset.duration varchar -> integer (milliseconds)
- removed isArchived instead use visibility
The /api/assets/albums-by-assets route accepts a POST body shaped
{ assetIds: string[] } and is invoked from the bulk-duplicate-finder
page with every asset across every duplicate group. With a large
duplicate set the body easily exceeds Next.js's default 1 MB
bodyParser limit and the route returns 413 before the handler runs.
Concrete case: a library with ~14,500 duplicate groups produces a
request body around 1.4-1.8 MB, which is rejected. The page renders
but never finishes loading (413 in browser console).
Fix: add the per-route Next.js bodyParser config to bump the limit
to 10 MB, leaving plenty of headroom for very large libraries while
still bounding worst-case request size.
Upstream already shows the selected ring + clickable check badge on each
thumbnail. This adds the missing piece for dense grids: a slight opacity
reduction on non-selected items while a selection is in progress, so the
selected set stays visible at a glance.
Implemented by passing selectionMode={selectable && selectedIds.length > 0}
from AssetGrid to LazyGridImage; LazyGridImage applies opacity-60 to its
container when selectionMode && !photo.isSelected.
- Updated importJobs schema to include 'ente' as a valid platform.
- Enhanced import-shared API to handle Ente shared links, including detection and fetching of albums.
- Introduced new ente.ts module for Ente-specific decryption and API interactions.
- Implemented thumbnail and video handling for Ente assets in import-shared API.
- Created EnteSharedLinkProcessor for processing Ente shared links during import jobs.
- Updated asset interfaces to accommodate Ente-specific encryption artifacts.
- Registered EnteSharedLinkProcessor in the import processors registry.
- Added necessary dependencies (bs58, libsodium-wrappers-sumo) to package.json and bun.lock.
- Updated FindInput component to use rc-mentions for better performance and flexibility.
- Removed unused styles related to react-mentions and added new styles for rc-mentions in globals.scss.
- Enhanced search functionality to handle mentions and clear input more effectively.
- Updated FindPage to manage searched queries and loading state.
Today the Analytics heatmap hard-codes "last 12 months" both in the SQL
(`WHERE fileCreatedAt >= CURRENT_DATE - INTERVAL '1 YEAR'`) and in the
frontend's month labels loop. Users with multi-year libraries can't look
back at 2018 or 2020 from this view.
Changes:
- API `/api/analytics/statistics/heatmap` now accepts an optional `year`
query param. With it, the query spans the full calendar year (Jan 1 to
Dec 31) and `fillMissingDates` walks that range. Without it, the legacy
rolling 12-month behaviour is preserved (including the "skip the
repeating current month from last year" seam guard).
- Response shape changed from `[]` to `{ data, year, availableYears }`.
`availableYears` comes from a DISTINCT EXTRACT(YEAR ...) over the user's
assets so the UI can render a correct dropdown without guessing.
- Component shows a Select next to the heatmap: "Last 12 months" (default)
plus one entry per year that actually has assets. Month labels and the
`weeksPerMonth` computation switch accordingly.
- No migrations needed; drizzle query only.
Callers of `getHeatMapData()` now receive an object — there was only one
caller (the heatmap component) so the change is localised.
Two small fixes in PeopleFilters:
1. `handleChange` preserved the current page when any other filter changed.
Symptom: the user is on page 2, types a name in the search box, and the
list shows zero results until they click back to page 1 manually. The new
query returns fewer total people, so page=2 is past the end.
Fix: force page=1 whenever the change doesn't explicitly set `page`.
2. The DropdownMenuTrigger for the sort menu had a leftover
`onClick={() => handleChange({ page: nextPage })}` — looks copy-pasted
from the "next page" button right above it. Opening the sort menu would
silently advance the pagination. Dropped; Radix's DropdownMenuTrigger
opens the popover by itself.
The previous guard 'only set if formData.albumName is empty' lost races against the dialog mount cycle: in some orderings the formData starts empty, the effect fires while config.suggestedAlbumName is undefined, then later when the suggestion arrives the guard refuses to update because prev.albumName == ''. Net effect: the user clicks a trip, selects photos, opens Add to Album, and the Album Name field is empty.
Track the last applied suggestion via a ref and write the value whenever the suggestion changes to a new non-empty string. Doesn't overwrite mid-typing because the suggestion only flips when the user picks a different trip; doesn't overwrite when the user picks the same trip twice; works on mount-after-suggestion (which was the broken path).
Varun Raj
jonvdveenandClaude Fable 5
Sai charan GuntupalliandGitHub
sai80082
tikibozo
David Gil Pérez
Varun Raj ManoharanandGitHub