Add API route for searching for sample using sample ids

[mhkc]

This PR adds a API route for searching samples using sample ids. The new route uses the POST HTTP method which enables many more parameters than a GET.

Closes #81 #80

How to setup and perform the tests

1. Set up bonsai and add 600 samples.
2. Create a group with all samples
3. Go to the created group page
4. Select all samples in the group and cluster them

Expected outcome

The operations should work.

Additional context

[alkc]

Am rerunning the test procedure because I forgot to add the samples to a group on upload. But can in the meantime confirm that selecting ~600 samples into basket and clustering them works without any issue.

[alkc]

Hmm, @mhkc I am running into some issues when clustering from a group view:

1. The group view sample table is populated by "empty" rows
2. Selecting all rows and clustering triggers a CORS error:

Cross-Origin begäran blockerad: Samma ursprungspolicy tillåter inte läsning av fjärrresursen på http://api:8000/cluster/cgmlst. (Orsak: CORS-begäran lyckades inte). Statuskod: (null).

3. I've made no changes to the ALLOWED_ORIGINS settings in docker-compose.

4. Selecting all rows and adding to basket triggers a JS error:

   Uncaught ReferenceError: addSelctedSamplesToBasket is not defined
   onclick http://localhost:8010/groups/saureus:1

5. Less importantly, repeated fails of cluster sample keep appending a warning symbol to the button.

I am guessing there's something wrong with the JS table?

Edit: Tested on local instance, accessed via Firefox 118.0.2 (64-bitars)

[alkc]

Also, adding the sample table in /groups works fine. So does adding samples to basket and clustering

[mhkc]

1. The group view sample table is populated by "empty" rows

There are no default columns when you create a new group. The columns have to be configured by the admin at this time.

2. Selecting all rows and clustering triggers a CORS error:

Are you running locally or on one of our servers? Which web browser are you using?

I dont get those errors on our dev servers. You probably need to update the CORSs configuration based on your local environment and browser.

4. Selecting all rows and adding to basket triggers a JS error:

Likely caused by improperly configured group and is not related to this PR.

5. Less importantly, repeated fails of cluster sample keep appending a warning symbol to the button.

Separate bug. File as a new issue.

[mhkc]

You have to edit the group and add the sample id column. The data type should be sampleid and the data path $.sample_id

[alkc]

Local instance via Firefox 118.0.2

Regarding 2. I think the error that claims to be a CORS error is due to the client making a call to http://{BONSAI_API_URL}/cluster/cgmlst from the browser here:

https://github.com/Clinical-Genomics-Lund/bonsai/blob/f9d441597b66affea7baad6a1f379d92c8c90d40/client/app/blueprints/groups/templates/group.html#L203-L204

When running a dev instance locally, that URL will be http://api:8000/cluster/cgmlst instead of, say, lennart:80/cluter/cgmlst when running on lennart.

[alkc]

Also the cause of 4 is not an incorrectly configured group. The add to sample basket button calls a function in addSelctedSamplesToBasket that does not exist or is imported in the template:

Uncaught ReferenceError: addSelctedSamplesToBasket is not defined

It only exists in the groups.html template.

[mhkc]

Local instance via Firefox 118.0.2

Regarding 2. I think the error that claims to be a CORS error is due to the client making a call to http://{BONSAI_API_URL}/cluster/cgmlst from the browser here:

https://github.com/Clinical-Genomics-Lund/bonsai/blob/f9d441597b66affea7baad6a1f379d92c8c90d40/client/app/blueprints/groups/templates/group.html#L203-L204

When running a dev instance locally, that URL will be http://api:8000/cluster/cgmlst instead of, say, lennart:80/cluter/cgmlst when running on lennart.

Strange. Running a split app on different ports works on the dev server. Perhaps Firefox treats external domains different than localhost?

[mhkc]

Also the cause of 4 is not an incorrectly configured group. The add to sample basket button calls a function in addSelctedSamplesToBasket that does not exist or is imported in the template:

Uncaught ReferenceError: addSelctedSamplesToBasket is not defined

It only exists in the groups.html template.

Good catch. Pushed fix

[alkc]

Local instance via Firefox 118.0.2 Regarding 2. I think the error that claims to be a CORS error is due to the client making a call to http://{BONSAI_API_URL}/cluster/cgmlst from the browser here: https://github.com/Clinical-Genomics-Lund/bonsai/blob/f9d441597b66affea7baad6a1f379d92c8c90d40/client/app/blueprints/groups/templates/group.html#L203-L204 When running a dev instance locally, that URL will be http://api:8000/cluster/cgmlst instead of, say, lennart:80/cluter/cgmlst when running on lennart.

Strange. Running a split app on different ports works on the dev server. Perhaps Firefox treats external domains different than localhost?

Is it though? I thought the URL/name http://api:8000 will only be reachable from inside the app container, not from a web browser running on the host.

On the production server the same API url will be mtlucmds1.lund.skane.se/bonsai/api/v1 which should work.

[mhkc]

Depend on your configuration. You have to configure the frontend to know the external API URL but that depends on how you have hosted the software. You configure the frontend either by changing the config.py or by setting the BONSAI_API_URL environmental variable.

But this is something that we need to add to the development documentation

[alkc]

Just to document stuff from our chat:

On a local development instance (e.g. started via docker compose on a local computer): Setting BONSAI_API_URL to the host computers local IP lets both the Flask client and user web browser contact the API.

With the recent commits and a properly configured group, selecting samples in a /group view and sending them to clustering works.

One issue when running this on a local machine is that the timeout set for the grapetree binary call might need to be increased from 15s to ~30s for the process to be able to finish when run locally, otherwise the process is killed before grapetree can chew threw all the sample data. That's a separate issue/PR though.