KatyTaylor
commented
1 month ago 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
Open yoldas opened 6 months ago
KatyTaylor
commented
1 month ago Coming out of Y24-099, this partially works:
KatyTaylor
commented
2 weeks ago More details below about tube rack state from Andrew, in the context of work he did for https://github.com/sanger/limber/issues/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
commented
1 week ago 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)
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 https://github.com/sanger/limber/issues/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:
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.