Conversation
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #5525 +/- ##
===========================================
+ Coverage 87.36% 87.42% +0.05%
===========================================
Files 1463 1464 +1
Lines 33005 33293 +288
Branches 3467 3524 +57
===========================================
+ Hits 28834 29105 +271
- Misses 4150 4167 +17
Partials 21 21 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
…e pooling submissions
…o separate module
…n data by request study/project instead of asset aliquot
| end | ||
|
|
||
| # Groups the requests associated with a submission by study and project. | ||
| def self.grouped_requests(submission) |
There was a problem hiding this comment.
I think requests and labware and synonymous as far as the grouping is concerned at this point. Favoured requests over labware as the study/project data is derived from the submisison rather than related aliquots.
There was a problem hiding this comment.
There is a request on each well. This method groups requests, hence wells because of request.asset, by "#{study} / #{project}".
There was a problem hiding this comment.
Saying this I have realised if they set number_of_lanes in submission to 2 this logic will not work as the submission will have double requests...
But I am not sure if they can / should do this for scRNA, it seemed to break the int suite setup I had. Maybe one for @KatyTaylor or the SSRs?
There was a problem hiding this comment.
I have added a uniqueness on assets in case multiple lanes are requested. Changes in fc5e0a6
…o Y25-016-scrna-submission-pooling-plan
…ator grouped_requests
…o Y25-016-scrna-submission-pooling-plan
| end | ||
|
|
||
| def scrna_core_cdna_prep_gem_x_5p_submission? | ||
| orders.first.template_name == SCRNA_CORE_CDNA_PREP_GEM_X_5P |
There was a problem hiding this comment.
Ah good find, I didn't know the template name was saved. Might be slightly more robust to check if any of the request types in the submission are the correct type... in case in future the cdna prep request type is chained together with another in a different template. But that could break too if the request type changes.
There was a problem hiding this comment.
Yes good point. I'm worried if we try support future submissions based off request type the logic might not hold up as we are basing this off the requests which might not work if the prep gem x 5p is not the first/primary request type.
| 'This submission does not have the correct template for downloading a scRNA Core cDNA pooling plan' | ||
| redirect_to submission | ||
| return | ||
| end |
There was a problem hiding this comment.
This is just being cautious, right, because the button shouldn't display in this case?
There was a problem hiding this comment.
Yes thats right. We have a unique URL that the button invokes so in theory it could be invoked by any submission so we are just guarding against it.
4 participants
Closes #5524
Changes proposed in this pull request
Notes
I have tested this against the int suite and confirmed the proposed pooling plan matches the actual pooling seen in LRC PBMC Pools 'Pooling information' section.
I think the next best test will be testing on Training and comparing real test submissions against with the real pooling information as it is difficult to simulate production runs.
TODO: Update confluence with additional pooling generator content.