Add Query String as URL Parameter is required to be completed before this one.

So, with the ability to save/share queries as base64 encoded strings, saving them becomes more straight-forward.

A new text field/button should be added underneath the "Filter Tests" section of the modal.

• The value of the text field will be the readable name of the query. It is not nullable, should be limited to 40 characters, and should have its surrounding spaces trimmed.
• The button should be the "Save for Later" button, and it will save the new query

There should also be a new dropdown to select a saved query instead of creating a new one. Here are some properties of the dropdown:

• The default placeholder should be "Enter or select query..."
• The dropdown values should be the saved query labels
• When a dropdown value is selected, it should populate the JSON editor with the decoded base64 query string value

To save data...

For now, we will utilize the browser's localStorage as a way of data persistence. This means that queries will not be persisted if the user clears their browser's storage, which I am sure will be somewhat annoying. Right now, OAR only requires a single Postgres table for test results, and we are going to stretch that for now. In the future I think implementing an optional redis instance might be a good way to go, but not necessary for now.

There is a writable store that connects to localStorage that might be appropriate for this use case from Skeleton UI: https://www.skeleton.dev/utilities/local-storage-stores

Now that the enrich UI is at MVP, it should be included in the README.md, as well as the new make commands to work with the enrich-ui locally. Should also include some documentation around the full OAR process with enrichment included, as I still think it is unclear from current documentation.

So filters on the enrich-ui need an easier way of being saved.

Here is an example query:

{
    "resolutions": ["Unresolved"],
    "docs": [
        {"owner": "Patrick Star"}
    ]
}

This gets base64 encoded and sent to the GET /tests endpoint to get a filtered set of tests.

In the UI, this process is performed in the filter modal:

As a UX improvement, it would be nice to have the filter that is applied to the test table to be dictated by a query URL parameter that is any base64 encoded query. This way, when a new filter gets applied to the test table, the URL will reflect the query.

This will make it easier to share, save, and modify test queries.

Whenever the enrich-ui table resets, it must reset the pagination offset too.

For example, if you scroll to page 5 on the pagination and then apply a filter that only returns enough results for 2 pages, the user has to manually scroll back 3 pages to get to the results. It sort of looks like there are no results at first glance when there really is.

Publish enrich-ui 0.0.1 image to Docker Hub

Marching ants test selection logic currently only works across a single page. The logic needs to be updated to work on each pagination page independently.

Minimum reproduction

1. Start with enough tests in the tests table to enable at least 2 paginated pages
2. Select the test in the first table index
3. Navigate to another page of tests
4. Select the test in the second table index

Issue: The selection animation in the second index behaves as if the test above it was selected, when it was actually only selected on the first page. It becomes more problematic if you are doing a lot of selecting/deselecting across multiple pages because the animation gets all kinds of screwed up.

When the enrich-ui cannot connect to the oar-service, it should return a more graceful error message that what is present. It can utilize the /health endpoint on startup to ensure connectivity between the service and the UI

Guide: https://docs.github.com/en/packages/working-with-a-github-packages-registry/working-with-the-container-registry

Trying to move everything to GH