Create a new API that checks a barcode on all 4 databases #1174
Labels
🧽 API - Quality
🤳🥫 blocking mobile apps
This issues are blocking a feature on the Open Food Facts mobile apps
Fixed ?
This issue might have been fixed. We can close them once we verify that they have.
help wanted
🧴 Open Beauty Facts
Our cosmetic analysis project https://world.openbeautyfacts.org
🐾 Open Pet Food Facts
Our pet food analysis project https://world.openpetfoodfacts.org
📸 Open Products Facts
Our project to increase the lifespan of objects. https://world.openproductsfacts.org
🎯 P0
Comments
|
One possibility could be to merge the 4 databases into one, and have a tag on each product to indicate which database(s ?) it is in. Issues with that:
|
|
An advantage would be that moving products would be much easier? |
teolemon
added
🧴 Open Beauty Facts
This was referenced Aug 21, 2021
teolemon
added
the
🤳🥫 blocking mobile apps
github-project-automation
bot
moved this to 💬 To discuss and validate
in 🤳🥫 The Open Food Facts mobile app (Android & iOS)
|
stephanegigandet
added a commit
that referenced
this issue
Nov 18, 2024
…OBF, OPF and OPFF (#10959) In the last few weeks, we normalized product barcodes and deduplicated products that existed in multiple flavors (Open Food Facts, Open Beauty Facts, Open Product Facts and Open Pet Food Facts). We are now going to merge the directories that contain product and product revision data (the .sto files) and the product images. We will keep separate MongoDB databases for each flavor. This will: - make it much easier to move products from one product type to another - remove the possibility of having duplicate products on multiple flavors - make it much easier to have read and write APIs that can be used to retrieve / update products of any type. Deployment plan: - stop OBF, OPF, OPFF for the duration of the migration (a couple of hours) - update OFF code - move products and product images dirs from OBF, OPF, OPFF to the OFF directory structure - change the links to products and products of images on OBF, OPF, OPFF to use the OFF dirs - restart OBF, OPF, OPFF with the new code In this PR: - code updates to check product_type when reading / editing a product for both the website and API. Redirect to the right flavor if the product type is different than the one of the server the request was made to. - changed the product edit form to allow moderators to change the product_type - keep support for moderators to put "obf" etc. in the change code field - tests for the above - small refactor to put into Config.pm things that are the same for all flavors and that are currently duplicated in Config_off.pm etc. Will solve: - #9221 - #7539 - #1174 - #497 - #320
very-smartin
added a commit
that referenced
this issue
Nov 20, 2024
unit tests Tackling recipes.t and attributes.t issues Tackling recipes.t issues Tackling recipes.t + attributes issues : correcting unit tests Tackling ingredients.t issues : correcting unit test Tackling ingredients.t issues : correcting unit test v2 Tackling unit tests for nutrsicore.t/ingredients.t refactor: merge the products and product images directories for OFF, OBF, OPF and OPFF (#10959) In the last few weeks, we normalized product barcodes and deduplicated products that existed in multiple flavors (Open Food Facts, Open Beauty Facts, Open Product Facts and Open Pet Food Facts). We are now going to merge the directories that contain product and product revision data (the .sto files) and the product images. We will keep separate MongoDB databases for each flavor. This will: - make it much easier to move products from one product type to another - remove the possibility of having duplicate products on multiple flavors - make it much easier to have read and write APIs that can be used to retrieve / update products of any type. Deployment plan: - stop OBF, OPF, OPFF for the duration of the migration (a couple of hours) - update OFF code - move products and product images dirs from OBF, OPF, OPFF to the OFF directory structure - change the links to products and products of images on OBF, OPF, OPFF to use the OFF dirs - restart OBF, OPF, OPFF with the new code In this PR: - code updates to check product_type when reading / editing a product for both the website and API. Redirect to the right flavor if the product type is different than the one of the server the request was made to. - changed the product edit form to allow moderators to change the product_type - keep support for moderators to put "obf" etc. in the change code field - tests for the above - small refactor to put into Config.pm things that are the same for all flavors and that are currently duplicated in Config_off.pm etc. Will solve: - #9221 - #7539 - #1174 - #497 - #320 Tackling check perl test taxonomy: Italian for bacon (#11027) Fix Italian for bacon fix: apidoc openApi ecoscore mapping (#11009) - [x] PR title is prefixed by one of the following: feat, fix, docs, style, refactor, test, build, ci, chore, revert, l10n, taxonomy - [x] Code is well documented - [x] Include unit tests for new functionality - [x] Code passes GitHub workflow checks in your branch - [x] If you have multiple commits please combine them into one commit by squashing them. - [x] Read and understood the contribution guidelines This PR introduces several improvements to the API documentation and schema organization: 1. **New Schema File for Country Codes** - Created a dedicated `country-code.yaml` file to centralize country code definitions - Introduced reusable `CountryCode` enum with all supported country codes - Added `CountryValues` schema to standardize country-to-number mappings - Commented out pattern properties in favor of generator-friendly alternatives 2. **Product Ecoscore Schema Improvements** - Refactored country-specific properties to use the new `CountryValues` schema - Added proper type handling for nullable integer fields (`transportation_score`) - Removed redundant pattern properties in favor of schema references - Enhanced type definitions for scores and values 3. **Packaging Schema Enhancements** - Added comprehensive examples for packaging properties - Added missing fields with proper examples: - `number_of_units` - `quantity_per_unit` and related fields - `recycling` - `weight_measured` 4. **Agribalyse Schema Updates** - Added `agribalyse_proxy_food_code` field - Added `agribalyse_food_code` field - Added `co2_agriculture` field The changes improve code organization, reduce duplication, and enhance compatibility with OpenAPI code generators while maintaining backward compatibility with existing data structures. - Fixes #[ISSUE NUMBER] This refactoring improves schema maintainability and provides better type safety through proper enum definitions and standardized patterns for country-specific data. feat: openApi refactor fields parameter to support multiple values with enum validation (getProductByBarCode/search) (#11012) This PR improves the OpenAPI specification for the `fields` parameter in the product and search endpoint. The changes make the API specification more accurate and provide better validation and documentation for the fields parameter, which is critical for controlling response payload size and structure. - Improves API documentation accuracy and completeness - Makes the fields parameter behavior more predictable and better documented - Helps API consumers understand available field options 1. Created new file `parameters/product_available-fields.yaml` to house fields parameter definition 2. Updated main API spec to reference the new parameter definition 3. Removed redundant fields parameter definition from individual endpoints 4. Added comprehensive enum of available field values 5. Added validation rules and examples - Verified that the OpenAPI spec validates correctly - Checked that the parameter definition matches actual API behavior - Confirmed that examples are valid and helpful Note: This change is purely to the API specification and does not affect the actual API implementation. chore: week47 (#11025) Mainly pine nuts clean up --------- Co-authored-by: Arnaud Leene <[email protected]> Tackling integration test docs: openapi for requested product type (#11028) Trying to upate the OpenAPI spec for reading products: - add new product_type parameter - add possible response codes (302 and 404) --------- Co-authored-by: Alex Garel <[email protected]>
teolemon
added
the
Fixed ?
github-project-automation
bot
moved this from To discuss and validate
to Done
in 🍊 Open Food Facts Server issues
github-project-automation
bot
moved this from To Discuss & Validate
to Done
in 🧴 Open Beauty Facts
github-project-automation
bot
moved this from To be triaged
to Done
in 🛠️ - Server - API
github-project-automation
bot
moved this from To do
to Done
in 🎯 Very high impact issues
github-project-automation
bot
moved this from 💬 To discuss and validate
to 🎊 Done
in 🤳🥫 The Open Food Facts mobile app (Android & iOS)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Create a new API that checks a barcode on all 4 databases (off, obf, opf, opff) and returns the name of the matching db, for moderation purposes.
Part of
The text was updated successfully, but these errors were encountered: