Y24-103 Tube Rack Banking Presenter

[yoldas]

User story
As PSD, we would like to support visualisation of Tube Racks in Limber similar to Plates using the versioned tube rack model proposed in Reuse of TubeRacks document.

Who are the primary contacts for this story
Abdullah, Katy, Andrew

Who is the nominated tester for UAT
Once #1713 and its dependencies are complete, we can ask Abby if she will UAT it. Could send some screenshots for earlier feedback.

Acceptance criteria
To be considered successful the solution must allow:

• Tube Rack can be presented similar to Plates
  - [ ] Additional tab shows listing of tubes contained within the rack and their coordinate (do we need this if we have the tooltips and clickable tube icons?) Decided not needed if we have tube icons and tooltips.
• Y24-486 - Relatives tab works as normal, display parents and children of the tube rack (not the tubes it contains) - see comment for more info. #2097
• Y24-103sa - Tube Racks Presenter - Suggested actions #2175
• Y24-484 - Button(s) for downloading files, e.g. driver files #2093
• Y24-498 - Button(s) for initiating bed verification and manual transfer #2108
• Y24-487 - Tooltips on tube icons #2098
• Y24-482 - State badge and state of tube rack #2090
• Tube Racks - Check Print Tube labels button in Rack Presenter #2138
• Update the integration suite tests as necessary.

It is not possible to release the implementation of this story in isolation. There are epic branches in use for SS, Limber and Int Suite to branch from and to.

Dependencies
Story relationships are shown in the Lucidchart diagram TubeRack Stories.

Additional context
The versioned tube rack model is researched in DPL-1011 Re-use of tube racks and the model is summarised in the Google Document DPL-1011 Re-use of tube racks

This story is part of re-implementation of DPL-811 Transfer PBMC isolations into FluidX tube racks (Banking) using the versioned tube rack model.

[KatyTaylor]

Coming out of Y24-099, this partially works:

• displays plate with tube icons instead of well icons
• tube representations are clickable and take you to the tube page

[KatyTaylor]

More details below about tube rack state from Andrew, in the context of work he did for #1696. It's relevant to the Relatives tab because the tab doesn't work if the labware state is nil.

---

TubeRackPresenter in Limber has a method for determining state from its racked_tubes. This might be better placed in the TubeRack model.
Tubes already handle state of course.

Code:
app/models/state_changers.rb in Limber contains classes TubeRackStateChanger and AutomaticTubeRackStateChanger.

For the TubeRackStateChanger I added a version of the contents_for method which (for plates) selects the well locations that need a state change. In this method I changed it to select the coordinates of the racked_tubes.

This information is part of the Sequencescape::Api::V2::StateChange that the code creates in the move_to! method, along with target_state, target_uuid etc.

The move_to! method seems to be called by the labware_controller and by bed verifications to transition state, and uses the api to sequencescape.

On the SS side we have app/models/state_change.rb, which takes the contents sent through the api and passes it to the target.state_changer.

state_changer is then delegated to purpose in the labware model.

The purpose models set the state_changer class to use, e.g. PlatePurpose includes a line:
self.state_changer = StateChanger::StandardPlate

NB. There is currently NO TubeRackPurpose or state_changer set up in SS for Tube Racks. I have NOT tested what happens when a tube rack state change is triggered. I expect it blows up as the list of coordinates passed is expected to refer to well locations in a plate.

State changers are defined in directory app/models/state_changer/ in SS. e.g. In PlatePurpose, method associated_requests is pulling out requests from the aliquots in the receptacles in the plate wells and updating their state.

If we implemented tube rack versions of these classes we would need something similar, for fetching requests from receptacles in the tubes from the racked_tubes in a tube_rack. There is some other stuff going on in these classes that needs considering too e.g. broadcasting events including library start for Orders, and updating transfer requests.
Or, we could use the existing TubePurpose state_changer, somehow calling that for each tube in the rack from the Limber side. But that seems inefficient.

[StephenHulme]

I would be interested to work on this - it looks like quite a large story though, so would prefer to split it up and share it with someone(s)

[andrewsparkes]

Story split into smaller sections as per task list.
Main outstanding points:

• suggested actions: should there be a green button to action the next step in the pipeline for the tubes in this rack? if there is, how do you determine what it should be given you are progressing a whole set of racked tubes and not just the one labware as is normal? In scRNA these tubes will need a submission created on them before they can progress. Maybe if all racked tubes have the same (valid) next step we create the button. The labware creator this calls would have to be able to accept the batch of tubes, rather than a single labware as normal. ie. many parents.