Cleanup Task to Delete incomplete Interviews

[michaelhofrichter]

A cleanup task should be to delete any incomplete interviews for the testing user. There are a couple of different API endpoints that might be useful here:

• https://docassemble.org/docs/api.html#user_interviews_delete
• https://docassemble.org/docs/api.html#user_interviews
• https://docassemble.org/docs/api.html#user_user_id_interviews_delete
• https://docassemble.org/docs/api.html#session_delete

[plocket]

Closed wrong issue, sorry

[plocket]

Brainstorming:

This may have an MVP and future improvements. For example, one complication is that one interview could open another interview.

• MVP: Delete only the interview initially created by the bot for the Scenario
• or MVP: Delete all interviews created through the "I start the interview" Step. I recommend abstracting this further since I already see the potential for future Steps that go to interviews in different ways.
• V2: Delete all interviews the bot creates during the whole run of all tests

Is it possible to use the API to give every session a tag so that we can just use the tag to delete all of the user's interviews at once? Maybe using the Project name as the tag? We probably need API access to session_tags(), which I think we'd have to write ourselves. Running as an admin can get any interview, not just the current user's interview, but we can't count on that permission level.

Note: We need to use the auth of the user running the interview, not the auth of the author's API key - sometimes authors "log in" as a different user to test different functionality. I think being in an interview and making a request without a different API key would work (never needed to try it), but can we count on being present in an interview at the time we need to delete it? The user could have navigated away from the interview.

We could change how we navigate to an interview so that each "I start the interview" (or similar) Step opens a new window/tab. When we close up a Scenario, we would delete the interview associated with that window/tab before closing it.

[plocket]

Given:

• To delete an interview with the API, the user needs to give us an API key to delete with.
• API keys should have the least permissions possible.
• We should limit ALKiln as much as is reasonable.

Then:

• ALKiln should assume the API key has the most limited permissions possible.
• ALKiln should limit its scope as well. ALKiln should only ever try to have a "user" delete their own interview, not allow an author/account to delete any interview on the server. Use only the api/user/interviews endpoint.

Note: We are deleting the interview with API keys. Deleting robotically is slow (introducing more incidental flake) and will run into complications because at some point folks are going to log in as different users in the same test, or use some other complex behavior, and that will be much harder to account for. This is a nice-to-have, not a critical feature. We don't want to make it burdensome if we can reasonably avoid it.

Additional work our authors will have to do:

• With an admin account, for the users that 1. log into interviews 2. for whom the author wants to delete old interviews, the admin must create an API key.
• Add that API key to the "sign in" Step.
• Add that as a GitHub secret or server config var.

Example of an author creating (and getting back) a new API key for a user:

curl -X POST \
  https://apps-dev.suffolklitlab.org/api/user/123/api \
  -H 'Content-Type: application/json' \
  -d '{
    "key": "yourAdminAPIKeyWhateverItIs",
    "method": "none"
  }'

This can be done for absolutely any user account.

Further things to consider:

• [x] Should we check the permissions of the API key instead of getting the id as a proxy for this check?

Warnings to add to the report:

• [x] optional API key github/config secret name was given, but doesn't exist
• [x] optional API key env var exists and has a value, but its permission level doesn't have access on the server allow the action (deleting a user's own interviews)
• [ ] optional API key env var exists, but has no value (is an empty string)

New tests to write:

API tests, no warnings

• [x] Not logged in
• [x] No API key present fails silently
• [x] (All valid) From local/github tests, type string, valid
• [x] Try to delete interview address after failing to go to the interview
• [x] Test from local/github, type non-string (undefined) (warning handled elsewhere)
• [x] Test from local/github, type string, 403 (access denied, warning handled elsewhere)
• [x] Test from local/github, type empty string (also 403) (warning handled elsewhere)
• [ ] From playground, type string (no attempt to delete). This is a hard one to test because it would have to be done manually or with a cron job or something. We don't have that set up yet.

API with warnings

• [ ] Test from playground, type non-string This is a hard one to test because it would have to be done manually or with a cron job or something. We don't have that set up yet.
• [ ] Test from local/github, type string, other error (not sure how to trigger)

Non-API warnings

• [x] API key var with missing env var (Test from local/github, type non-string (undefined))
• [x] API key var is an empty string (is this feature necessary or useful?) (403, but that's incidental)
• [x] API key has no access on server (403)