You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
User story
If a run is mid-way and fails, or ends a run partially complete (end of day run, no sources remaining) we need an option for the user to scan the destination plate barcode directly into a LIMS screen (as robot method trigger step not reached) to either a) generate plate from Dart data so it can continue in pipeline partially filled or b) fail plate with a reason from a list.
Who are the primary contacts for this story
Scott T
Ops (Rich C?)
Acceptance criteria
To be considered successful the solution must allow:
For creation: Scan entry of a destination plate barcode, selection of a robot, entry of a user if cannot be got automatically, 'create plate in LIMS' button triggers standard destination creation process that generates the plate in the LIMS and created the same set of events as a normal completion on the robot would have.
For failure: Scan entry of a destination plate barcode, selection of a robot, entry of a user if cannot be got automatically, choice of failure reason from a list, 'fail plate in LIMS' button. Creates a destination failed event of some type here that will record what we know about any samples lost.
Dependencies
This story is blocked by the following dependencies: #145
Additional context
Aim is to 'save' destination plates as much as possible. Samples when transferred leave nothing behind in the source plate, so if we cannot recover the destination then those samples are 'lost'.
If we know what samples are being 'lost' in the failed plate, these should be recorded in an event, such that PAM or others running reporting can find this failure event and understand what happened to those samples.
It will be important that Ops have a procedure in place for failed plates, to make them use this screen, as well.
Implementation Details
The screen failure/creation screen should exist in lighthouse-ui. The UI should call endpoints in the lighthouse backend. The creation operation should call the existing cherrypicked-plates/create?... endpoint (#145); the failure operation should call a new cherrypicked-plates/fail?... endpoint which will send an event to the warehouse as per https://ssg-confluence.internal.sanger.ac.uk/display/PSDPUB/Cherrypicking+Events
The text was updated successfully, but these errors were encountered:
rl15
changed the title
GPL-nnn As a user I would still like to process the destination plate if there is a partial failure
GPL-714 As a user I would still like to process the destination plate if there is a partial failure
Oct 23, 2020
harrietc52
changed the title
GPL-714 As a user I would still like to process the destination plate if there is a partial failure
GPL-714-1 As a user I would still like to process the destination plate if there is a partial failure (Lighthouse)
Dec 2, 2020
Chris-Friend
changed the title
GPL-714-1 As a user I would still like to process the destination plate if there is a partial failure (Lighthouse)
GPL-714-2 As a user I would still like to process the destination plate if there is a partial failure (Lighthouse)
Dec 2, 2020
User story
If a run is mid-way and fails, or ends a run partially complete (end of day run, no sources remaining) we need an option for the user to scan the destination plate barcode directly into a LIMS screen (as robot method trigger step not reached) to either a) generate plate from Dart data so it can continue in pipeline partially filled or b) fail plate with a reason from a list.
Who are the primary contacts for this story
Scott T
Ops (Rich C?)
Acceptance criteria
To be considered successful the solution must allow:
Dependencies
This story is blocked by the following dependencies:
#145
Additional context
Aim is to 'save' destination plates as much as possible. Samples when transferred leave nothing behind in the source plate, so if we cannot recover the destination then those samples are 'lost'.
If we know what samples are being 'lost' in the failed plate, these should be recorded in an event, such that PAM or others running reporting can find this failure event and understand what happened to those samples.
It will be important that Ops have a procedure in place for failed plates, to make them use this screen, as well.
Implementation Details
The screen failure/creation screen should exist in lighthouse-ui. The UI should call endpoints in the lighthouse backend. The creation operation should call the existing
cherrypicked-plates/create?...
endpoint (#145); the failure operation should call a newcherrypicked-plates/fail?...
endpoint which will send an event to the warehouse as per https://ssg-confluence.internal.sanger.ac.uk/display/PSDPUB/Cherrypicking+EventsThe text was updated successfully, but these errors were encountered: