Files
lightcraft/docs
Chad ElliottandClaude Opus 5.5 5981ecadbb Issue #2165: a Lightroom collection that can't nest goes under the nearest set instead of failing the import (#3145)
* Issue #2165: place a Lightroom collection that can't nest where it is under the nearest set

Lightroom Classic keeps a saved print, book, slideshow or web gallery inside a plain collection, but a
LightCraft album nests only in a folder. The importer passed that collection as the album's parent,
AddAlbum rejected it with "parent must be an existing folder", and the atomic batch rolled back every
album and every catalog-only photo (#2165: photos but no collections; #2532: nothing at all).

An album whose Lightroom parent isn't a collection set (plain, smart, a saved creation, system-only or
missing) now joins the nearest set above it, or the top level, and the import report names it under
warnings. Before each AddAlbum the parent is checked against the catalog's rule (an existing folder,
or one added earlier in the batch), so no album can fail the batch. Builds on #2168 by @endthestart.

Fixes #2165, fixes #2532.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* Issue #2165: a Lightroom collection never silently loses its album; warnings name the set as the library does

- Two collections never share an album. An album id the counter hands out that is already taken (the counter
  saturates, so a damaged one repeats) stops the import with an error naming the collection, as AddAlbum's
  "album exists" did before; it no longer drops the second collection and its photos while the report counts it.
  A collection listed twice imports once when both rows are the same and stops the import when they differ. An
  index that names one existing album for two collections gives the second an album of its own.
- A relocation warning names the destination set as this library calls it (a set renamed after an earlier import),
  and a set whose earlier album isn't a folder is described as such, not as "not a collection set".
- The staged-album set is no longer called `added`, which #3142 uses for its photo count in this function.
- Tests: relocated re-import, a user-moved album on re-import, a renamed destination set, a set album that isn't a
  folder, sets nested under a plain collection, an exhausted album counter, duplicate collection rows and an index
  naming one album twice.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(lightroom): name the Lightroom collection id in relocation warnings (#2165)

A collection imported somewhere other than where Lightroom keeps it now ends
its warning with "(Lightroom collection N)", so two collections that share a
name can be told apart, as #2165 asked for.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* fix(lightroom): a collection listed twice costs only the duplicate (#2165)

A different collection under the id of an earlier one stopped the whole
import. Like any bad Lightroom record it now costs only itself (#1588):
the first row of each id is kept, in catalog order, and a different one
is left out with a warning naming both; the photos listed under that id
go to the first. A row repeated as it is still drops quietly. The
warning reads as the one #3152 gives, so the import behaves the same
whichever of the two lands first.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

* test(lightroom): the nearest-set search ends on a parent loop or a deep chain (#2165)

`collection_parent` follows a collection's parents to the nearest set
with a seen-set and a 64-level cap. `validate` refuses loops before it
runs, so no import test reached that guard: a unit test now gives it
A in B in A, a collection in itself, a child of that loop (with and
without a set in it) and a 100-deep chain of plain collections. The
duplicate-collection test also checks that an exact repeat gives no
warning.

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

---------

Co-authored-by: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-05 20:49:39 +01:00
..
2026-11-02 20:41:34 -05:00
…
2026-10-24 22:28:38 +04:00
2026-10-31 02:31:16 +00:00