Refresh submission keys in more cases

[matthew-white]

Filing an issue based on this forum topic: https://forum.getodk.org/t/draft-submissions-not-accessible-when-project-is-encrypted-missing-passphrase-prompt-to-decrypt/36133

Right now, when submissions are refreshed (in either the Submissions tab or the Testing tab), we do not refresh the submission keys. That helps reduce the number of requests and usually works fine, with the thought that it is rare for there to be a change in the submission keys. However, in some cases, this leads to the "Decrypt and Download" modal not being shown: the user is not prompted for the passphrase.

The forum topic describe this use of the Testing tab:

• Create a form draft for an encrypted project.
• Navigate to the Testing tab.
• Create a submission.
• Refresh the submissions.
• Download the submissions: the modal is not shown.

I also remember @lognaturel encountering an issue like this in the past. I think the issue then went something like this:

• Create one or more submissions for a published form in a project that is not encrypted.
• View those submissions in the Submissions tab.
• In a different browser tab, encrypt the project.
• Create additional submissions using the new form version. These will be encrypted.
• Refresh the submissions in the first tab.
• Download the submissions in the first tab: the modal is not shown.

I think we decided that this second sequence was uncommon enough that we didn't need to make a change. However, the first sequence sounds like a more common workflow that I think we should address. (Maybe we should refresh the submission keys whenever we refresh the submissions. Or maybe we could refresh the submission keys only when there were previously no submissions: that wouldn't solve the second sequence, but it would solve the first.)

Either way, there is some complexity here because of how the components are set up: SubmissionList is the component shared between the two tabs and sends most of the requests, but it is the two separate tab components (FormSubmissions and FormDraftTesting) that send the requests for the submission keys.

[ktuite]

QA observed related behavior in the "Analyze via OData" button on the submissions table (and entities table, coming in 2023.2).

Steps to reproduce

1. start with an encrypted project
2. add a new form
3. look at submissions for that form when there are 0 submissions - button is disabled
4. press "new" and make a new submission in a new tab
5. press "refresh" on submission page - new submission appears AND button becomes enabled
6. reloading the entire page with 1 or more submissions - button is disabled again and stays disabled

Looking into it, I think the cause is this: when the submission list is loaded with 0 submissions and there's a request to submission keys, that response comes back as an empty array. When there are new submissions and the "refresh" button is pressed, the submission keys aren't refetched/refreshed until the page is fully reloaded. Whether or not to show the button is based on the presence of these keys and number of submissions.

This is another case for refreshing the submission keys when the submissions are updated, but that requires figuring out which component should be in charge of that.

[ktuite]

@getodk/testers I believe we fixed the underlying issue that caused a bunch of these problems.

This is how I was testing it while working on it:

1. start with an encrypted project
2. add a new form
3. look at submissions for that form when there are 0 submissions
   • observe that odata button is disabled
   • observe that download submission modal doesn't show password input when there are 0 submissions (true for both draft and regular)
4. in another tab or with enketo in a new tab, submit a submission
5. click refresh to load new submission
   • observe that odata button stays disabled
   • observe that the download modal now has passphrase input for both draft and regular submissions

[matthew-white]

I believe we fixed the underlying issue that caused a bunch of these problems.

I think so too. @getodk/testers, you can see issues mentioned above that referenced this one as the underlying cause.

[srujner]

Tested with Success!

[dbemke]

Tested with Success!