Cross referencing container updates on the security page

[begunfx]

Was thinking through the usefulness of the security scans for containers, and thought it would make sense to add an update button next to containers on the security page if updates are available? That way a user could take action on a container after reviewing the security scan results.

[scttbnsn]

Makes sense. The security page already has the data — it knows both "what CVEs this container has" and "is there an update available" — we just aren't surfacing the action inline. An "Update" button on rows where an update exists is a small UI change on top of APIs that already exist.

Tracked for v1.6.0, slotted alongside the scanner runtime decoupling work since that's where the security page is already getting some attention. Noted and tracked.

[scttbnsn]

Update: this shipped in v1.5.0-rc10 (pulled in from the v1.6.0 timeline noted above).

What landed:

• Inline Update button on Security rows where an update is available
• Single container → opens the update dialog directly. Multiple containers → popover to pick the instance, then the same dialog
• Secondary View in Containers deep-link that filters the Containers view to just the affected containers
• Inline Release notes link next to the action — structured notes when the registry provides them, plain external link otherwise
• Real-time refresh: the Security page subscribes to the container-changed SSE stream so update state stays fresh after an operation completes

Pattern is aligned with Snyk / Dependabot / Docker Scout — read the scan, act on the finding, review the changelog, no page navigation required. Thanks for the suggestion.

[begunfx]

This is great. Seeing it now in rc10. One call out, however. If you have a container that is a pinned version AND you have the Hide Pinned set in the container view. Clicking the View in Containers will take you to the container page with no results because the selected container has been hidden by the Hide Pinned option. I think there are a few ways to address this. The least friction/problematic route would probably be that if you filter for a single container then that will override the Hide Pinned behavior. That would allow for you to still search for individual containers (which is probably what the user wants anyway by doing this search, regardless if they hide pinned option is checked) AND would allow for this cross security/container view behavior to work as expected.

[scttbnsn]

Confirmed the bug, fixed on the next-RC branch.

Root cause

View in Containers builds a /containers?containerIds=... link. The Containers view's displayContainers was applying that id filter on top of filteredContainers — which has already applied the saved filter state, including Hide Pinned. So a pinned deep-link target was removed by Hide Pinned before the id filter ran, and the view rendered empty.

Fix

When containerIds is set, source from the raw container list instead of filteredContainers. A deep-link is a directed lookup — the user named the exact container(s) they want, so filter state shouldn't be able to hide them.

I went slightly broader than your suggestion: instead of special-casing Hide Pinned, the deep-link bypasses all filter criteria (Hide Pinned, kind, status, server, registry, search). Same reasoning extends to any of them — if a user deep-links to a container, they shouldn't need to remember which filters they left checked on their last visit. Single mental model: deep-link wins, full stop.

Regression test asserts the exact scenario you hit — a pinned container with a pending update, Hide Pinned active, deep-linked by id — and confirms displayContainers still surfaces it. Tagged (#299) so future refactors can't silently drop the behavior.

Ships in the next RC. Thanks for the screenshot — made the bug obvious.

[begunfx]

Working now. Feel free to close this. Thanks!