…uidProbe` (#15867)

re AUTH-591

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview

<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

Send and save the CSV RTPs used in protocol runs to the new table
created in the database, and hook it up to the GET endpoint that fetches
all the data files used in analysis and run.

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->
- run test files to ensure that csv rtps get insert to the new
run_csv_rtp_table and able to get them from the table

## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->

- Added `run_csv_rtp_table` to schema_6.py file
- Added runTimeParameterFiles field to the run creation request model 
- Passed rtp files input onto the Run Orchestrator’s load process
- Added `insert_csv_rtp()` and `get_all_csv_rtp()` function
- Updated `get_reference_data_files()` to add file referenced in runs
- Updated tests

---------

Co-authored-by: shiyaochen <[email protected]>
Co-authored-by: Sanniti <[email protected]>

… and runs to set in-protocol values (#15855)

# Overview

Closes AUTH-419.

This PR hooks up the setting of runtime parameter files in the POST
`/runs`, `/protocols` and `/protocols/{protocolId}/analyses` to the
actual `CSVParameter` object used in the protocol context.

This file is sent via a dictionary of parameter name and file-id, so we
resolve the file-id into a `Path` by using the `data_files_directory`
and `data_files_store`. This is then passed to the `ParameterContext`
and used to open up a temporary file that contains the contents of the
actual file stored on the robot.

## Test Plan and Hands on Testing

Tested end to end via the following protocol and two CSV files

```
metadata = {
    'protocolName': 'CSV End to End Test',
}

requirements = {
    "robotType": "Flex",
    "apiLevel": "2.18"
}


def add_parameters(parameters):
    parameters.add_str(
        display_name="Pipette Name",
        variable_name="pipette",
        choices=[
            {"display_name": "Single channel 50µL", "value": "flex_1channel_50"},
            {"display_name": "Single channel 1000µL", "value": "flex_1channel_1000"},
            {"display_name": "Eight Channel 50µL", "value": "flex_8channel_50"},
            {"display_name": "Eight Channel 1000µL", "value": "flex_8channel_1000"},
        ],
        default="flex_1channel_50",
        description="What pipette to use during the protocol.",
    )
    parameters.add_csv_file(
        display_name="CSV Data",
        variable_name="csv_data",
        description="CSV file containing labware and volume information."
    )



def run(context):
    PIPETTE_NAME = context.params.pipette

    trash_bin = context.load_trash_bin('A3')
    tip_rack = context.load_labware('opentrons_flex_96_tiprack_50ul', 'D2')

    pipette = context.load_instrument(PIPETTE_NAME, mount="left", tip_racks=[tip_rack])
    csv_file_data = context.params.csv_data.parse_as_csv()

    labware_name = csv_file_data[1][0].strip()
    location = csv_file_data[1][1].strip()
    volume = float(csv_file_data[1][2])


    labware = context.load_labware(labware_name, location)
    pipette.pick_up_tip()
    pipette.aspirate(volume, labware.wells()[0].top())
    pipette.dispense(volume, labware.wells()[1].top())
    pipette.drop_tip()
```

```
Labware Name, Location, Volume
opentrons_96_wellplate_200ul_pcr_full_skirt, C1, 20
```

```
Labware Name, Location, Volume
nest_96_wellplate_100ul_pcr_full_skirt, C2, 30
```

## Changelog

- Resolve `runTimeParameterFiles` into a dictionary of `Paths`
- pass the `run_time_param_paths` all the way to the `ParameterContext`
where they can be opened as temporary file handlers
- close the file handlers upon protocol end
- Allow importing of `CSVParameter` from the `protocol_api` namespace.

## Review requests


## Risk assessment

Medium.

---------

Co-authored-by: Sanniti <[email protected]>

Closes RQA-2895

* fix(app)switch navlink to useNavigate for tabas in run setup

…15887)

Closes RQA-2902

Refactor useTipAttachementStatus to provide only one pipette with tip at a time.

…ktop (#15882)

fix PLAT-438, PLAT-440, PLAT-441, PLAT-439, PLAT-442, PLAT-443, PLAT-444

# Overview

According to new modal designs for labware/adapter/module stacks on
desktop and ODD, we need to render an isometric view of each element of
the stack, maintaining the topography of each stacked element. The
isometric views are constructed by transforming and aligning the labware
SVG (top face) along with two new rects (front and left side). All three
are scaled, skewed, and rotated at 30˚ angles or its derivatives
([reference](http://jeroenhoek.nl/articles/svg-and-isometric-projection.html)).

The "bottom" labware definition is an optional prop, so we have an
affordance for rendering an isometric view of a single labware from the
same component. The user can choose to highlight both or none of the
labware in the stack, resulting in a fill of blue30.

In addition, adapters are handled in the following way:
- If the adapter is used as the top definition and there is no bottom
definition, we render the non-transformed `LabwareAdapter` svg
- if the adapter is used as the bottom definition, we render the
isometric transform of the well-less adapter face. _**NOTE**_ In this
PR, the adapter's height is maintained, but we may also consider setting
the height for a bottom adapter as a constant, rendering a
standard-height rectangular prism with well-less face.

Closes [PLAT-374](https://opentrons.atlassian.net/browse/PLAT-374),
[PLAT-377](https://opentrons.atlassian.net/browse/PLAT-377),
[PLAT-394](https://opentrons.atlassian.net/browse/PLAT-394),
[PLAT-375](https://opentrons.atlassian.net/browse/PLAT-375)

…5883)

# Overview

closes https://opentrons.atlassian.net/browse/EXEC-504.
add an end point in runs router to fetch commands error list. 

## Test Plan and Hands on Testing

- Post a protocol that will cause a recovery workflow.
- Start the run and let the command fail.
- Resume from recovery.
- Let the run end.
- GET `/runs/{runId}/commandErrors` and make sure you are getting the
full command error list.

## Changelog

- added an end point to commands router `/runs/{runId}/commandErrors`.
- added logic in `CommandsState` to `get_error_slice`.

## Review requests

naming makes sense? changes make sense? location for the new route makes
sense? (under commands router)

## Risk assessment

low. adding new logic

Closes RQA-2842

Migrates the logic for building RunProgressMeter's step copy to its own utility, cleaning up the order of operations slightly. Refactors the final step text from nothing to "N/A" when the run is canceled before starting.

Closes RQA-2890

changes the deck hardware and labware map views from modals to page content. alters the floating action button to remove the default icon.

closes PLAT-391, PLAT-392

…ise `MustHomeError` (#15900)

Co-authored-by: Ed Cormany <[email protected]>

Fix RQA-2908, RQA-2848, RQA-2906

In the run page on both app and ODD, you get an indication of completion
when you get all your instruments and modules and deck stuff present and
calibrated. But those are just two of the steps presented equally in the
run setup page, and the rest of the steps don't get anything similar. It
leads people to wonder whether they've set things up properly.

This PR adds similar styling and completion semantics for the other
tasks in the run setup screen to fix this issue. Specifically, LPC gets
a "confirm offsets" button (which will confirm offsets even if you
haven't run LPC - makes it more apparent that that's a separate option)
and labware and liquids get generic confirm buttons.

There's also a couple other visual fixes:
- On desktop, the "back to top" button in run setup is now where figma
thinks it is, outside the run-setup content area. This allows some
refactoring of component props
- On desktop, there was an issue with the react-router upgrade (I think
- it's also in the latest IR alpha) that means that if you had an
ongoing run, you couldn't view anything but run details without getting
instantly navigated back to run details

This implements this figma:
https://www.figma.com/design/Rwdt9R0aERFC55oTLDTlqY/8.0-September-Release-File?node-id=39-35830&t=l6vwJjQsfyVeovfC-4

## To come out of draft
- [x] implement for ODD
- [x] rebase onto release
- [x] "are you sure" modal on desktop
- [x] "are you sure" modal on ODD

## Review requests
- This is some pretty complex UI - do you agree with how I've done this?
- Some of this is pretty ugly, in large part because this is old code
that I'm cleaning up. There's some duplicated logic in the run details
and some pretty ugly typing. What I'd like to do is merge this since it
implements some features nicely and then follow up with a refactor to
get the size of some of these files down and enforce nicer separation
between everything.

## Testing
- [x] Desktop green checks on flex
- [x] Desktop green checks on OT-2 (yes, this has to be different
because the steps can be different here)

Closes RSQ-7

…tocolContext.define_liquid()` (#15906)

…5913)

<!--
Thanks for taking the time to open a Pull Request (PR)! Please make sure
you've read the "Opening Pull Requests" section of our Contributing
Guide:


https://github.com/Opentrons/opentrons/blob/edge/CONTRIBUTING.md#opening-pull-requests

GitHub provides robust markdown to format your PR. Links, diagrams,
pictures, and videos along with text formatting make it possible to
create a rich and informative PR. For more information on GitHub
markdown, see:


https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

To ensure your code is reviewed quickly and thoroughly, please fill out
the sections below to the best of your ability!
-->

# Overview
Should have realized it was wrong when I had to change the test
<!--
Describe your PR at a high level. State acceptance criteria and how this
PR fits into other work. Link issues, PRs, and other relevant resources.
-->

## Test Plan and Hands on Testing

<!--
Describe your testing of the PR. Emphasize testing not reflected in the
code. Attach protocols, logs, screenshots and any other assets that
support your testing.
-->

## Changelog

<!--
List changes introduced by this PR considering future developers and the
end user. Give careful thought and clear documentation to breaking
changes.
-->

## Review requests

<!--
- What do you need from reviewers to feel confident this PR is ready to
merge?
- Ask questions.
-->

## Risk assessment

<!--
- Indicate the level of attention this PR needs.
- Provide context to guide reviewers.
- Discuss trade-offs, coupling, and side effects.
- Look for the possibility, even if you think it's small, that your
change may affect some other part of the system.
- For instance, changing return tip behavior may also change the
behavior of labware calibration.
- How do your unit tests and on hands on testing mitigate this PR's
risks and the risk of future regressions?
- Especially in high risk PRs, explain how you know your testing is
enough.
-->

Co-authored-by: caila-marashaj <[email protected]>

Closes RQA-2904

The logic for rendering InterventionModal on the ODD/Desktop is a little bit different when looking at the exact conditions, and this (likely) causes the InterventionModal to render on the ODD sometimes but not on the desktop app, and vice versa.

This is a good opportunity to refactor all of this logic into its own hook and use that hook where we render InterventionModal. After thinking through the render logic, there's room to simplify it a bit, too. We don't actually need stateful storage of an intervention command key. Also, I decided to separate showModal from modalProps (which lets us pass all the non-null props simply), even though we could technically just do a truthy check for modalProps for rendering InterventionModal, since this is maybe a bit more intuitive. Lastly, a few missing tests are added.

To help with bug testing intervention modals, I added a couple console.warns.

To give clarity to the contents of labware/adapter/module stacks, here,
I add a modal when clicking
a stack on Labware setup deck map (for both Desktop and ODD). Each
element of the stack will be
highlighted described in a list item containing the element's name,
optional nickname, and isometric
SVG or PNG representation depending on its type.

Closes [PLAT-376](https://opentrons.atlassian.net/browse/PLAT-376),
[PLAT-378](https://opentrons.atlassian.net/browse/PLAT-378)

let's not push code with syntax errors

init

reduce number of single channel pickups

init

let's not push code with syntax errors

init

remove duplicated file