Integration of the new price tag workflow

[raphael0202]

As price tags and price tag predictions are now saved in the backend (see openfoodfacts/open-prices#628, openfoodfacts/open-prices#629, openfoodfacts/open-prices#630, openfoodfacts/open-prices#631), we should now integrate it in the front-end.

Price validator

We should create a new page (for now, in the experiments section?), where users could validate the prices.

A quick mockup of what it could look like:

For simplicity, we could display a single price tag, with the original proof (and bounding boxes) on the side.

3 buttons:

• one to delete the price tag (incorrect detection)
• one to mark the price tag it is not readable
• one to send the prices

In all cases, once we hit one of these 3 buttons, we display the same interface for the next price tag.

Step 1: fetch all price tags with null status

With a GET https://prices.openfoodfacts.org/api/v1/price-tags?status__isnull=True.

The proof and the price tag predictions are returned, under the proof and predictions fields respectively.

Take action

For each price tag, the user can:

• validate the extracted price, possibly after correction of Gemini extraction
• delete the price tag
• mark the price tag as not readable
• link the price tag to an existing price in the prices table

Validate the extracted price

Create a price using the usual creation endpoints (POST /api/v1/prices), then update the price tag status and link the price by PATCHing the price tag:

PATCH /api/v1/price-tags/{ID} with a JSON body with price_id={PRICE_ID} and status=1 (linked_to_price)

Marking the price tag as not readable

with PATCHing status to 2 (not_readable)

Delete the price tag

If the price tag is not really a price tag (wrong detection by the model), the user can delete it:

DELETE /api/v1/price-tags/{ID}
This call changes the status of the price tag to 0.

Link the price tag to an existing price

This is the trickly case. If some user (user A) already created a price using the usual interface, we don't know to which price tag the price belongs to. We don't want the user who validates the price (user B) to create a new price, but we want to link the price tag to the price created by user A.

Linking to an existing price is done just as above, with a PATCH /api/v1/price-tags/{ID} with a JSON body with price_id={PRICE_ID} and status=1 (linked_to_price).

One way to make it easy for the user is to fetch all prices associated with the proof, and to compare the price that is about to be created with existing prices. If the price to be created and another price have the same EAN (or the same product category), we ask whether we want to link the price tag with the existing price.

We have an interest in linking the backlog of prices in DB to a price tag instance for 2 reasons:

• it's easier to check the price if we know the bounding box of the price tag where this info came from (it currently sometimes takes me a while to check the data when I look at proofs)
• this data is necessary to train an extraction model to replace Gemini

So we could also create a "linking" game to link existing price to price tags.

Fix the price tags bounding box

The object detector can make mistakes: miss some price tags, or incorrectly crop some ones.
We should be able from an dedicated interface to:

• draw new bounding boxes
• update the position of the bounding boxes

in either case, the Gemini predictions are computed automatically after creation/update.

To create a new price tag:
POST /api/v1/price-tags with a JSON body with proof_id={PROOF_ID} bounding_box:='[0.1,0.2,0.3,0.4]' The bounding box is in the format (y_min, x_min, y_max, x_max) in relative coordinates (0-1), with the upper-left corner as origin.

To update one:
PATCH /api/v1/price-tags/{PRICE_TAG_ID}