Implement Progress API

[atruskie]

Implement the following endpoints for the new progress models.

• Controller: ProgressEvents
  • /datasets/{dataset_id}/progress_events (GET & :index, POST & :create)
  • /datasets/{dataset_id}/progress_events/filter (GET & :filter)
  • /datasets/{dataset_id}/progress_events/{progress_events_id} (GET & :show, DELETE & :destroy)
• Controller: ProgressEventsSummary
  • /datasets/{dataset_id}/progress_events/summary (GET & :index, POST & :filter`)

Note: we will not support updating progress events

---

• Make controllers for ProgressEvents and ProgressEventsSummary items (can use rails console)
• Ensure controller definitions match the idioms found in our existing controllers
• Add acceptance specs to cover all routes and user combinations
• Add appropriate documentation to our Wiki about these new endpoints
• Ensure creating new progress events for the Default dataset works automatically

[peichins]

Proposed permissions for progress events:
Update and Delete:

• Progress events are not updatable or deletable.

Create

• Any user needs to be able to create progress events for the dataset item they are viewing/playing/annotating.
• Currently, dataset items just inherit permissions from projects via
  project/site/audio_recording/dataset_item.
• Proposal: A user can create a progress event with a given dataset_item_id if that dataset item belongs (indirectly) to a project they have read access on.

View / index / filter

• Users may need to see progress of other uses on their projects.
• Users may need to see their own progress.
• Progress events will be used to sort dataset_items for citizen science projects. However, this should be done within the dataset_items filter response on the server, so it probably doesn't impact the index, view or filter permissions on progress events.
• Proposal: Users have read access on progress events if
  • they belong indirectly to a project the user has read access on.
    • Does this means everyone will be able to see everyone's activity on public projects?
  • they are the creator of the progress event. This should be a subset of the above anyway, unless access to a project is revoked.

[atruskie]

Progress events are not updatable or deletable.

We'll allow admin roles to update and delete for maintainability.

Proposal: A user can create a progress event with a given dataset_item_id if that dataset item belongs (indirectly) to a project they have read access on.

Sounds good. We already have code that is very similar to this. Once you have a reference to the audio recording there's a standard function for this.

Users may need to see progress of other users on their projects.
Yes.
Looking forward though, this will probably be exposed by another endpoint like progress_report where produce some kind of aggregate report.

Progress events will be used to sort dataset_items for citizen science projects. However, this should be done within the dataset_items filter response on the server, so it probably doesn't impact the index, view or filter permissions on progress events.

Yes this querying will be internal to the controller.

Proposal: Users have read access on progress events if

• they belong indirectly to a project the user has read access on.

Yes

• • Does this means everyone will be able to see everyone's activity on public projects?

Yes. We already have this concept - you can view public details of other users' activity now. This information might be quite a bit more detailed so some aggregation may be required.

• they are the creator of the progress event. This should be a subset of the above anyway, unless access to a project is revoked.

It's troubling that project access revocation removes your own record of activity. However, I think it is a suitably simple model given that I don't know of project revocation ever happening.

---

On reflection read permissions here should be similar to those of dataset_items: If you have access to the recording, you have access to the progress event. Unlike dataset items, a user can create their own progress events.

Thinking about this a little more, I wonder if we can remove the create permission from progress_events in the system? If we consider our users hostile actors, they could create as many progress events as they like. The model seems wrong. The more we open our API up, the more I'm concerned with public users being able to mass insert records. We already know we have spam user accounts in our system; now we're giving them write access to a table when they only have read permission everywhere else.

Moving all to server

For the states we need to record:

Activity	Automatic trigger
Dataset Item View	???
Media Download	On /media
Playback	???
Audio Event Creation	On /audio_events insertion
Validation	Future work
CS Response	On /citizen_science_labelings insertion

Only playback and view can't be measured by an associated database record.

Securing the client

An alternative idea would be ensuring some parts of our public API can only be used in certain contexts. In this case, only our SPA app should be creating progress_events.

I have no idea how to do this.

Moving forward

Go ahead with your suggested implementation. Ensure you file a new issue with these problems highlighted if we can't work out how to solve them between now and the PR.