feat: #349 - added support for Events API

[monsieurtanuki]

Still missing: couldn't test how to create an event. Are we talking about the same users as in the "official OpenFoodFacts" API? (aka "off off"). Good news is that the TEST env works - which is not the case for Folksonomy.

New files:

• api_events_test.dart: Tests around Events API.
• BadgeBase.dart: Events API: badge.
• BadgeBase.g.dart: generated
• EventCreate.dart: Events API: event create.
• EventCreate.g.dart: generated
• events.dart: Client calls of the Events API (Open Food Facts).
• EventsBase.dart: Events API: event.
• EventsBase.g.dart: generated
• LeaderboardEntry.dart: Events API: leaderboard entry.
• LeaderboardEntry.g.dart: generated

Impacted files:

• JsonHelper.dart: added a nullable timestamp conversion method.
• OpenFoodAPIConfiguration.dart: added host entries for Events API.
• openfoodfacts.dart: exported new Events related files.
• UriHelper.dart: added Events related method getEventsUri.

• Fixes Add support for the openfoodfacts-events API (leaderboard, badge and gamification system) #349

[teolemon]

Oh great :-) gamification in Smoothie 🎉

[M123-dev]

Looks good, thanks @monsieurtanuki good start that it is in it's own class

[monsieurtanuki]

Thank you @teolemon @M123-dev for your review!

As mentioned earlier, there's one method that I could not test, the only one that writes: "create events", because I get the following error: Incorrect username or password.
@ocervell in my tests I saw that you were the only user with Events data in TEST and PROD environments: where do the Events users come from? Are they supposed to be "standard" open food facts users or are they specific to Events - if so how are they created?

[monsieurtanuki]

@ocervell ping

[ocervell]

@monsieurtanuki events are currently created by the admin user, set on the API side by the env variables ADMIN_USERNAME and ADMIN_PASSWORD. Initially we were not supposed to expose that to the client-side, so the OFF API should contact it, not the client app.

The request flow should be:

• User in app responds to questions / adds a product / etc...
• API call made to off-server backend
• off-server backend authentifies to Events API using admin credentials and adds the event

The problem with client app authenticating directly to the Events API is that anyone could add as many events as they want by simply using the API, thus falsifying the data (imagine if I just trace the API calls to events API I could add myself 20 "product_add" events and thus increase my score artifically).

[teolemon]

Oh, I really goofed on that one. I'm so sorry.

[ocervell]

Note that only the CreateEvent method is obsolete, the rest is still valid (querying badges for a user, querying leaderboard, querying events ...) so the PR is still mostly valid.

[monsieurtanuki]

Thank you @ocervell for your answers.

If I understand correctly, that means that we need the off backend to directly call CreateEvent each time an "event" is detected, like "product_add". And there's nothing we have to do on the app side, except read/count the events, right?

[ocervell]

Yes, that's correct, robotoff and the OFF backend will have code to contact the Events API CreateEvent endpoint internally. There might be an exception for the 'invite_shared' event as this is an in-app event but we could add an API call in off backend for that one (or just remove that event).