feat: Filter Storage Mode Responses by Submission Id

[frankchn]

Problem

Users have trouble finding specific responses and trying to download attachments for these responses.

Solution

This introduces a new textbox which filters submissions by reference ID so users can jump to a certain response immediately.

Screenshots

[frankchn]

Some design help for the "no responses found screen/table" and the exact placement for the filter textbox will be much appreciated.

[jonathangohjy]

Have uploaded screens on Zeplin for implementation

Placement of search bar
No Results screen

[frankchn]

@liangyuanruo can you take a look? this is pretty close -- I just don't have the SVG for the "filter" icon.

[liangyuanruo]

Hey @frankchn ,

I just tried it out the feature, and noticed a few things

1. I see @jonathangohjy has introduced the filter button, but I would like to revert the implementation back to a search bar without the filter button instead. The reason is because we expect users to copy-paste the ObjectID into the input box from the downloaded CSV, and we want the search to be immediately responsive, instead of introducing another click for the user interaction - I'd suggest using the ng-change directive here with the <input> element. We'd also need to introduce a debounce (I believe ng-model-options provide that out of the box).

2. File upload functionality appears to have been broken, although this may be to do with another PR related to CSP headers - could you rebase and see if it fixes the issue?

[frankchn]

@liangyuanruo Thanks for the comments! I updated the functionality per your suggestion in (1) and tested (2) to verify that file upload works with the latest rebase.

[liangyuanruo]

Just tested this branch on the staging environment - the database query isn't using existing indexes when the ObjectID is included in the query, triggering a collection scan and eventual 504 Gateway Timeout.

I think we'll have to investigate further on what's the best way to improve this. Some of the steps in the aggregate pipeline is clearly unnecessary if a query is only going to return metadata of a single response, so perhaps we could cater to 3 query types

1. Valid submission ID included - return single result (TODO)
2. Invalid submission ID - return empty output (done)
3. No submission ID - execute existing production query

You can force push to staging branch if you'd like to test out the performance on a production-scale dataset:

git push -f origin frank-search-response:staging

[frankchn]

OK I guess if MongoDB isn't quite smart enough to use the index, we will just have to do a single item query.

[frankchn]

@liangyuanruo Tested on staging and both attachment upload and filtering should work now that we switched to Submission.findOne instead of using the same mechanism.