Repository navigation
Add barcodes to custom foods - #69
Merged
Merged
Conversation
Cronometer keeps barcodes on the food object as a list of bare digit strings, and add_food accepts that list on create and on the full-object re-save that edits use. A custom food saved with a barcode is found when that barcode is scanned in the mobile app. create_custom_food and update_custom_food take `barcodes` (on update it replaces the whole list; [] clears it). Codes are normalized and their GS1 check digit verified, so a digit misread off a label is rejected instead of saved as a code that never scans. get_food_details now returns the food's barcodes.
rwestergren
requested changes
Oct 13, 2026
rwestergren
left a comment
rwestergren
left a comment
Owner
There was a problem hiding this comment.
Looks good - just an organization change
As requested in review: normalize_barcodes and its check-digit helpers now live in their own module, with their tests in tests/test_barcode.py. normalize_barcodes drops the leading underscore since client.py imports it across modules; the code is otherwise unchanged.
rwestergren
approved these changes
Oct 13, 2026
rwestergren
left a comment
rwestergren
left a comment
Owner
There was a problem hiding this comment.
Looks good, thanks for the contribution
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
2 participants
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.
Custom foods can now carry product barcodes, so a food created through
the MCP server is found when its package is scanned in the Cronometer
app.
Cronometer keeps barcodes on the food object as a list of bare digit
strings:
get_foodon a branded food returns e.g.["602652270284"],and on a custom food
[]. Verified against the live API on a throwawaycustom food, using the same
add_foodpayloads this change sends:barcode and left nutrients and measures unchanged
found the custom food
find_food(search_foods) does not match barcodes, so the tooldocs say so
Changes:
create_custom_foodandupdate_custom_foodtakebarcodes. On update it replaces the whole list ([]clears it,Noneleaves it alone) and is validated before the food is fetched,like the serving arguments.
_normalize_barcodesstrips the spaces and dashesbarcodes are printed with, requires 8, 12, 13 or 14 digits and
verifies the GS1 check digit, so a digit misread off a label (for
instance by a model reading a photo) is rejected instead of saved as
a code that never scans. 8-digit codes are accepted as EAN-8 or as
UPC-E. A UPC-E check digit belongs to the UPC-A it abbreviates, so
without the expansion the real 8-digit codes on small packages would
fail the check.
barcodes, andget_food_detailsnowreturns the food's barcodes so a caller can add one to the existing
list.
Notes:
create_custom_foodnow always sends"barcodes"([]when noneare given). Every custom food edit already re-sends
barcodes: []through
add_food, so the server accepts it.13-digit EAN with a leading 0 are not merged, since it is untested
whether the app's lookup treats the two forms as the same.