Allow directing new products to other projects

[teolemon]

What

• [ ] Allow directing new products to other projects
  • [ ] Allow to pick the project
  • [ ] Make it possible to send the API route on the fly for the product addition screen
  • [ ] Redirect to a prompt to install the other apps (for the time being, and just for OBF in the case of iOS)

Why

• People keep adding non-food items to Open Food Facts (and even thank us for cosmetic support which isn't there)

Mockup

Part of

• 1378

• 4543

[teolemon]

[g123k]

To clarify what is required here:

• If the product exists -> No change
• If it doesn't:
  • First check if it's available in the OFF galaxy (OBF, OPF…) -> if true, open the website
  • If it's not available at all, ask the type of product to the user
    • If it's food -> "Fast track"
    • Otherwise -> Only take photos

[g123k]

@monsieurtanuki Before implementing anything, I would like to know if you have some recommendations/advices for this flow. More specifically, we have to call the getProduct method for each environment.

[monsieurtanuki]

• First check if it's available in the OFF galaxy (OBF, OPF…) -> if true, open the website

I just see a loop on all "flavors" (except OFF of course).

• If it's not available at all, ask the type of product to the user

OK

* If it's food -> "Fast track"

OK

* Otherwise -> Only take photos

Not convinced. Anyway we should save the name, brands too. We'd still put products with the wrong flavor in OFF server and locally, with no means to discriminate them.

This is what I suggest - maybe you had that already in mind but this was not explicit.

1. add a "flavor" column to DaoProduct, defaulting to 'off' (for history + SQFlite limitations reasons only)
2. from now on, when we save a product locally we need to save the flavor too (a bit like what we did with language)
3. possibly we should be able to upload data to the correct server only (and limited to name brands and picture upload except for OFF) - I don't know if the flavored APIs are ready for that
4. each time we refresh a product list, we'll have to list the flavors and run the refresh for all products in their flavor
5. that API/server thing only makes sense if products have enough compatibility - json-wise - including names, images and basic structure

Quickly said.

[teolemon]

FYI @g123k @monsieurtanuki @stephanegigandet is now getting the server ready for this, and you can actually test the new data structure using the DEV mode and https://world.new.openproductsfacts.org/ For development purposes (to avoid waiting for server support), we could add the product_type key to all products when you have https://world.new.openproductsfacts.org/ as root url in dev mode (assuming devs wipe their DB each time they switch projects)

[teolemon]

The servers for OPF, OBF, OPFF are now live at https://world.openproductsfacts.org/ https://world.openbeautyfacts.org/ https://world.openpetfoodfacts.org/