Backfill recipe names when importing shared QR cards - #61
Merged
Conversation
The QR payload checks only that a field has the right type. Value rules live in the FujifilmRecipeData validators, which raise plain ValueErrors when the query builds the dataclass: an over-long or non-ASCII name, or a sensor name this deployment does not know. The card import catches only QRCodeNotFoundError and InvalidQRRecipePayloadError, so one such card aborted the whole upload rather than being recorded as a single failed file. Translate those ValueErrors into InvalidQRRecipePayloadError with a new "invalid_field_value" reason, so the offending card lands in the failed list and the rest of the batch imports. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
set_recipe_name published RECIPE_IMAGE_UPDATED, which describes a different state change: nothing about a recipe image changes when a recipe is named. The constant stays, because process_image publishes it correctly when it updates an existing image row. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A recipe shared as a QR card is matched against the library by its settings, so importing one usually takes the get path, where name and description are only create-time defaults. The name on the card was therefore dropped, which is the whole point of sharing a named recipe. Name an existing recipe from the incoming data, but only when it has no name of its own: a name chosen locally is never overwritten, and the description is never touched (a card does not carry one). get_or_create_recipe_from_data keeps its contract, so the EXIF and manual creation callers are unaffected. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The operation may now name the recipe a card matches, so a get_or_create name would promise less than it does. Its one caller keeps discarding the outcome for now; the use case starts reporting it next. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
A bulk import of shared cards mostly matches recipes the library already has, so "100 recipes imported" says nothing about what actually happened. Split the successes into the recipes the import created and the ones it completed by naming them. The EXIF importer shares the result type and cannot tell the two apart, so both fields default to empty there and imported stays the whole story. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
Importing a batch of shared cards mostly matches recipes the library already has, so "100 recipes imported successfully" left you unable to tell whether anything landed. Report how many recipes the import created and how many it completed by naming them. The counts, not the recipes, go into the template context, and the line is omitted when there is nothing to report -- including for the EXIF importer, which shares this partial and cannot tell the two apart. Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
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
1 participant
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.
Previous behaviour
A card is matched against the library by its settings. If a recipe with those
settings is already there, the import reuses it instead of adding a second copy.
Reusing it never touched its name: a name is only ever set at the moment a
recipe is first created.
The problem
Sharing a named recipe with a library that already has that recipe
transferred nothing. The name on the card was silently dropped.
What this PR does
A recipe that is matched but has no name now takes the name from the card.
A name chosen locally is never overwritten, and the description is untouched
(cards don't carry one).