Image transfer between OFF and OPF/OBF/OPFF #9221
Labels
🧴 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
OxF
Comments
teolemon
added
🧴 Open Beauty Facts
|
You're quite right @Sebleouf. This is related to the rearchitecture of Product Opener to handle more gracefully products of any kind. Related issues
|
github-project-automation
bot
moved this to To Discuss & Validate
in 🧴 Open Beauty Facts
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]>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
What
[I hope this issue doesn't already exists, I couldn't find the documentation for it.]
There are currently two cases:
the barcode does not exist on the target site, so all the images and data on OFF can be transferred to the target site
the barcode already exists on the target site, an error message appears "Please correct the following errors: A product already exists with the new code". It is therefore impossible to transfer an image and/or data to the target site.
This possibility needs to be unblocked, and I imagine it can be done by following the same principle of moving images from one product to another, which has worked very well on OFF for many years.
The challenge would be to empty this category (over 2,000 products) for example: https://world.openfoodfacts.org/category/open-beauty-facts; which is far from complete (I think there is more than 10k). This would allow more photos in the target projects and also improve the overall quality of the OFF database.
Once I've solved this problem, I'll be able to transfer the photos to thousands of products myself, as this is very important to me. However, if it's already possible to automate the transfer to the OBF category, that would be great!
Thank you in advance for dealing with this issue.
Part of
The text was updated successfully, but these errors were encountered: