Y24-190: Support Limber with Submission creation

[sdjmchattie]

Closes #4244

Changes proposed in this pull request

• Add support for creating Submissions from a list of Orders and then submitting them.
• Update tests for this new functionality.

Instructions for Reviewers

[All PRs] - Confirm PR template filled
[Feature Branches] - Review code

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.20%. Comparing base (bfccde3) to head (0b22fe1).
Report is 23 commits behind head on develop-Y24-190.

Additional details and impacted files

@@                 Coverage Diff                 @@
##           develop-Y24-190    #4555      +/-   ##
===================================================
+ Coverage            89.18%   89.20%   +0.02%     
===================================================
  Files                 1405     1405              
  Lines                29967    29980      +13     
===================================================
+ Hits                 26725    26745      +20     
+ Misses                3242     3235       -7     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dasunpubudumal]

This shared example seems to declared in spec/requests/api/v2/qc_files_spec.rb, spec/requests/api/v2/submissions_spec.rb and in spec/requests/api/v2/shared_behaviour/labware_shared_behaviour_spec.rb.

And all of them seem to be doing the following:

1. Checking if the response is an HTTP succes.
2. Checking if the call returns only one resource.
3. Checking if the call returns the correct resource.

Maybe we can move all these declarations into somewhere in shared_behavior directory and reuse it?

[sdjmchattie]

In case @StephenHulme picks this up (please feel free), I've implemented something like this in my Qcable work. So probably best to reuse that and go through existing tests, looking to replace this pattern with the shared example.

Shared example:
https://github.com/sanger/sequencescape/blob/Y24-190-support-limber-v2-qcable/spec/requests/api/v2/shared_examples/requests.rb#L138-L150

Usage:
https://github.com/sanger/sequencescape/blob/Y24-190-support-limber-v2-qcable/spec/requests/api/v2/qcables_spec.rb#L30-L57

[sdjmchattie]

I have now done this!

[andrewsparkes]

Looks good, thorough tests again.
Couple of minor questions.

[andrewsparkes]

Curious about that restriction and also state being read only.
Wondering if we need to be able to directly update submission state. Or if's all done indirectly through requests...

[sdjmchattie]

This pull request takes an endpoint that could not previously be created or updated (i.e. it was immutable) and adds a create POST endpoint while still leaving the update PATCH endpoint turned off. If we need to update state, it's not needed so far, but could be enabled carefully in future. immutable in the resource effectively adds , only: %i[show] to the route without explicitly writing it. I think it's a poor choice by the gem creators and they should expect you to just add that annotation to the routes file instead so it's explicit. As it is, you cannot tell from the routes alone which are immutable and which are full access.

[andrewsparkes]

what's going on with this change (and the one below)?

[sdjmchattie]

Hmm yeah that isn't clear from these changes alone is it? The SubmissionsController has a dubious method override in it which modifies the fields being returned by the API to only be the [uuid,name,state,created_at,updated_at] set if you didn't specify. As such, our tests for including relationships fail for ones that aren't in that set. I don't think there should be a default set of fields that you have to override in your request, but it's an existing endpoint and I don't want to break usage somewhere. So instead I make the request in the test explicitly ask for the one relationship to be included in the response (and no other fields for that matter). As that's the only field we want to check for anyway, it's more optimal, but that's not why I implemented it this way as I agree it's ugly and should be unnecessary for any other resource.