ternandsparrow / wild-orchid-watch-pwa

Progressive Web App for the Wild Orchid Watch citizen science project
https://app.wildorchidwatch.org
4 stars 4 forks source link

Support missions #38

Open tomsaleeba opened 4 years ago

tomsaleeba commented 4 years ago

iNat has no support for missions so we need:

The technical requirements are:

One option we thought of it to use the "journal" feature of projects. Journal posts allow some styling and we can create hidden elements so it would be possible to create a post that announces the new mission and encode the JSON (or whatever) data for the mission itself into the post. It's not ideal but it does mean we keep everything on the iNat platform and we can easily leverage the existing auth role system.

Right now, it seems that journal posts are not maintainable by all managers of a project, only by the user that created it. Looking at the code, it feels like the intent is for any manager to be manage any post but that doesn't seem to be working: https://github.com/inaturalist/inaturalist/blame/17a58ce8f352e6d6822c33d820599c763ad3fbac/app/models/project.rb#L301

As for a mission editor, we can add the functionality to the app. We already have the OAuth and API calling infrastructure so we'd just need to craft a webpage that asks for the relevant data and then creates a journal post in the correct format. We should probably put a hidden comment in the post that says you should NOT edit it by hand otherwise bad things might happen.

If that's not suitable, we can still create a separate webpage as the editor and host it on Firebase or AWS S3. It can use iNat OAuth for login.

tomsaleeba commented 4 years ago

After a technical meeting, we will go ahead with storing the data as a journal post. The NodeJS API doesn't expose the create/update methods we need for posts, only GET, so we'll either need to add that or see if we can hit the Rails API.

If we do need to change the NodeJS API to add the endpoints, we need the iNat team to deploy it. This means we should put the mission stuff behind a feature flag so we can turn it off and deploy to prod even if the real iNat doesn't have our code changes to the API deployed.

We might be able to "store" winners (or results) as comments on the journal posts. If we're really worried about people faking results by posting comments directly, we could always add some sort of digital signature.

On a separate topic, as a fallback in case the changes to the NodeJS API don't get deployed in time (or at all), we might be able to hit the Rails server directly using our JWT in the Authorization header (and posting JSON) and things work. We only get prompted for the authenticity token when we don't have a JWT. The key thing will be if CORS blocks us.

Here are the PRs that add /posts CRUD endpoints to the API: https://github.com/inaturalist/inaturalistjs/pull/28 https://github.com/inaturalist/iNaturalistAPI/pull/187