feat: Start of product rules: simple rule format

[stephanegigandet]

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:

1. Evaluate them. e.g. count how many products would be affected.
2. Execute them and apply their actions to complete products.

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).

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[alexgarel]

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

[alexgarel]

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 ?

[stephanegigandet]

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.

[stephanegigandet]

condition: $yoghourt_witch_sugar&ingredients_tags_en=sugar

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).

[teolemon]

• I can share this collaborative list of potential rules from the Regex Engine folder: https://docs.google.com/spreadsheets/d/1v62INXh8cKqyHXXKnj1nsGBb6KaICu14tV8f1uPrWHs/edit#gid=0
• Here's the folder of Regex Engine, which adopts a web-based, collaborative and iterative approach, with a rules database and rules management: https://drive.google.com/drive/u/1/folders/1YY8NM-7MIXNYPlBhI0JSjK-P1Rv36FZC

[teolemon]

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 origins:en: rule

[alexgarel]

@stephanegigandet why is this PR stalled ?

[teolemon]

@alexgarel @stephanegigandet because at this point, it's a manifesto. There's only a config file, but no actual execution

[teolemon]

I'm adding a P1, because everyone agrees the potential of the idea/feature.

[teolemon]

• Associated issue: Tag rules: Tag A + Tab B = Tag C #3426

[alexgarel]

@teolemon put it in discussion for next call maybe ?

[sonarcloud]

Kudos, SonarCloud Quality Gate passed!   

0 Bugs
0 Vulnerabilities
0 Security Hotspots
0 Code Smells

No Coverage information
No Duplication information

[codecov-commenter]

Codecov Report

Merging #6188 (d4f2117) into main (aa1f4eb) will not change coverage.
Report is 4 commits behind head on main.
The diff coverage is n/a.

@@           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!