Keep track of sessions by user

[suhlrich]

We need a way to keep track of 'successful' sessions for each user - regardless of if they've deleted them or not. A successful session is when they've collected a trial that is not calibration or neutral, and its status==done.

Here's a way we could do it:

opencap-core: when a trial finishes processing a dynamic trial and status == done, we could do a POST sessions/session_id/add_successful_session

opencap-api: sessions/add_successful_session checks some list for the user of successful sessions and adds the session if it doesn't yet exist.

Open to other ideas, @olehkorkh-planeks

[olehkorkh-planeks]

@suhlrich I have a few questions.

First of all, as I understand, we need to implement the API endpoint that allow to "mark" the given session as a "successful". That API endpoint will be used by opencap-core. We can also add the boolean field to the Session model, like is_successful and set it to True when opencap-core will invoke the endpoint. The only moment, I propose to use a bit different URL: sessions/session_id/set_successful.

opencap-api: sessions/add_successful_session checks some list for the user of successful sessions and adds the session if it doesn't yet exist.

This part is not clear for me. Do you want the endpoint for bulk operation. Like

POST sessions/set_successful
Authentication Token user_token
{"session_ids": ["session_id_1", "session_id_2", "session_id_3"]}

And the response would be like:

{
    "session_id_1": {"updated": true, "created": false},
    "session_id_2": {"updated": true, "created": false},
    "session_id_3": {"updated": true, "created": true},
}

Where updated shows if the value of is_successful has been changed (from False to True, for example). It can be false if you run the same request second time. The created attribute is true if the new session has been created.

Do you need also some sort of endpoint for getting the list of successful sessions? Or, just adding the list filter to the Session section in the admin UI is enough?

[suhlrich]

The sessions/session_id/set_successful endpoint is good. It does not need to return anything, and it should only be accessible if the user is admin or backend. We don't need an endpoint explicitly that sets it to false.

We will also need an endpoint that gets a list of successful sessions ids for a user (doesn't need to return the whole session, just the id). Let's add a query parameter `just_n' that is false by default. If true, it returns just the number of successful sessions for the user, if false, it returns all of the session identifiers.

[suhlrich]

@olehkorkh-planeks following up on your questions and making it a bit more general.

Changing the plan a bit: let's just create a status field in the Session model and create an endpoint to change the status.

Permissions: isAdmin, isBackend

POST /sessions/session_id/set_status
Authentication=user token
data = {'status'='successful'}

In the Sessions model, default status='init':

Question: when we migrate the database, the previous sessions will get the status field added with the default value, right?

Answers to your questions:

1. We do not need the ability to do it in bulk, so POST sessions/session_id/set_status will work

2. We do need an endpoint to get the list of sessions:

Permissions: isAdmin, isBackend, isOwner

GET sessions/get_status
params = {'status'='successful',
                  'date_range'=[beginDate, endDate]
                 }
Authentication Token user_token

status is an optional paramer. Default, return session_ids of any status
date_range is an optional parameter. Default is across all time. Let's express time in Unix time format.

response. We just want the session id string, not the full session model.

{session_id1, session_id2,...}

[olehkorkh-planeks]

@suhlrich @antoinefalisse

Please check the PR https://github.com/stanfordnmbl/opencap-api/pull/156/files

There are two endpoints:

POST /sessions/get_session_statuses/ - returns session ids with a given status in the specified range

## session get_session_statuses
curl -X "POST" "http://localhost:8000/sessions/get_session_statuses/" \
     -H 'Authorization: Token 8188103f9aa87cedda86587822db8c7ffbec01c2' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "status": "init",
  "date_range": [
    "2024-01-01",
    "2024-01-24"
  ]
}'

Response:

[
  {
    "id": "8e8f8bd2-2295-4786-8186-35098c9c9287"
  },
  {
    "id": "c06cee1f-bc12-469c-9d8b-057867b7a9db"
  },
  {
    "id": "654c8dc1-5794-41f9-8ea2-a5339292d936"
  },
  {
    "id": "feeb5bbd-0e5a-42c3-a123-2f3e8eb02ad1"
  },
  {
    "id": "64d9ccd2-d771-4c51-9917-e356fe343a7b"
  },
  {
    "id": "994aeb61-20be-4e66-be42-86a435df4185"
  },
  {
    "id": "6c256f1c-3660-41b9-b050-ca1642595e3d"
  },
  {
    "id": "3cbc7dc8-6b1b-4d5f-841a-df7a19902e94"
  },
  {
    "id": "14427e93-5429-494c-913c-bf7fef693734"
  }
]

POST /sessions/...session_uuid.../set_session_status/ - set the status for the specified session

## session set_session_status Duplicate
curl -X "POST" "http://localhost:8000/sessions/5747af67-5eb9-4282-8215-4cccdef4082f/set_session_status/" \
     -H 'Authorization: Token 8188103f9aa87cedda86587822db8c7ffbec01c2' \
     -H 'Content-Type: application/json; charset=utf-8' \
     -d $'{
  "status": "blah"
}'

Response

{
  "status": "blah"
}