-
-
Notifications
You must be signed in to change notification settings - Fork 383
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat: Start of product rules: simple rule format #6188
base: main
Are you sure you want to change the base?
Conversation
Kudos, SonarCloud Quality Gate passed! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Overall I'm ok but you should detail more, maybe.
I like the idea that we stay close to the API, such that adding more functionalities to API = adding more functionalities for filtering rules.
I wonder if we could quickly also have a mean to define conditions that are re-usable because this could helps readability (and I think this is easily done in perl).
like:
condition:yoghourt_without_sugar: categories_tags_en=yoghurts,-sweetened yoghurts
condition: $yoghourt_witch_sugar&ingredients_tags_en=sugar
|
||
# conditions: 1 or more conditions, in the same format as the search API v2 (makes copy and pasting easy to test rules) | ||
# e.g. https://world.openfoodfacts.org/search?categories_tags_en=yoghurts,-sweetened%20yoghurts&ingredients_tags_en=sugar | ||
# - conditions are comma separated, and can also be specified on several conditions: lines |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
you should detail:
do we do an "and" on all conditions ?
Or do we do an "and" on conditions on same line, and "or" between lines ?
Or do we do an "and" on conditions expressed with "&" sign, and an or between those, separated by comma or line ?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We do an "and" on all conditions. Initially I thought to have only 1 conditions: line, but then I'm thinking it could be more readable to have multiple lines.
e.g. in yoghurts.txt we could have all rules targeting yoghurts, and so the first conditions: line could be just to check that the category is yoghurts.
We could do something like that, but then we lose a bit the ability to quickly test conditions by copying and pasting them in a URL. (or we need to make sure we see all the $ signs and replace them accordingly). |
|
I fixed and harmonized the IGP entries in the taxonomies (from countries:en: to origins:en:) in #6196 to create space for impact for an |
@stephanegigandet why is this PR stalled ? |
@alexgarel @stephanegigandet because at this point, it's a manifesto. There's only a config file, but no actual execution |
I'm adding a P1, because everyone agrees the potential of the idea/feature. |
|
@teolemon put it in discussion for next call maybe ? |
Kudos, SonarCloud Quality Gate passed! |
Codecov Report
@@ Coverage Diff @@
## main #6188 +/- ##
=======================================
Coverage 47.95% 47.95%
=======================================
Files 65 65
Lines 20277 20277
Branches 4914 4914
=======================================
Hits 9724 9724
Misses 9301 9301
Partials 1252 1252 📣 Codecov offers a browser extension for seamless coverage viewing on GitHub. Try it in Chrome or Firefox today! |
An idea that was discussed with contributors during the "OFF days" this weekend is to enable the creation of rules that can be applied automatically to products to complete their data.
For instance if a product is the yoghurts category, and one of its ingredient is sugar, then we could add it to the sweetened yoghurts category if it's not in there already.
This PR is to propose a simple rule format that we can use internally in Product Opener to store rules and apply them.
I chose a simple text format (similar to the taxonomies) so that it can easily be read/written without a specific interface, and so that we can have diffs in github.
If we create a specific interface to experiment with rules, test them, validate them etc. we could of course have that tool output such a format. So it doesn't mean that people will need a text editor to propose rules.
Once we have rules defined, we can then do different things:
The execution of the rules can be done in real time (anytime products are saved) and/or in batch.
The application of the result of the rules (e.g. a new category) can be done either on the source data (adding a category as if it was added by a user), or the resulting data (adding a category but only on the resulting data, a bit like we extract ingredients from the ingredients list each time we save the product).