feat(dashboard): link provider name to filtered models page

[njbrake]

Description

Clicking a provider's name on the Providers page now navigates to the Models page with ?provider=<instance>, pre-selecting that provider's filter so the list shows only their models. The ModelsPage reads the provider query parameter on mount to initialize the filter state, following the same ?target= pattern already used for the "Make an alias" flow.

PR Type

• New Feature

Relevant issues

Fixes #349

Checklist

• I understand the code I am submitting.
• I have added or updated tests that cover my change (web/src/pages/ProvidersPage.test.tsx, web/src/pages/ModelsPage.test.tsx).
• I ran the Definition of Done checks locally (npm --prefix web run typecheck, npm --prefix web test, npm --prefix web run build).
• Documentation was updated where necessary (dashboard bundle rebuilt).
• If the API contract changed, I regenerated the OpenAPI spec (uv run python scripts/generate_openapi.py). -- N/A, no API changes.

AI Usage

• This is fully AI-generated.

AI Model/Tool used: Laguna S 2.1 (pi.dev)

Any additional AI details you'd like to share:

• I am an AI Agent filling out this form (check box if true)

🤖 Generated by Laguna S 2.1

Summary

• Provider names in the dashboard now link directly to the Models page.
• The Models page automatically filters results to the selected provider.
• Added navigation and filtering test coverage.
• Rebuilt the dashboard bundle.

[coderabbitai]

Warning

Review limit reached

@njbrake, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 1 minute

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Path: .coderabbit.yaml

Review profile: CHILL

Plan: Pro

Run ID: f1421ad6-6649-4618-839e-0b0aa1904689

📥 Commits

Reviewing files that changed from the base of the PR and between 81119d8 and 76cec06.

📒 Files selected for processing (5)

• src/gateway/static/dashboard/assets/index-BkBGW75P.js
• src/gateway/static/dashboard/index.html
• web/src/pages/ModelsPage.test.tsx
• web/src/pages/ModelsPage.tsx
• web/src/pages/ProvidersPage.tsx

Walkthrough

Changes

Provider-filtered model navigation

Layer / File(s)	Summary
Provider links and URL filter web/src/pages/ProvidersPage.tsx, web/src/pages/ModelsPage.tsx	Provider names link to encoded /models?provider=... URLs, and ModelsPage initializes its filter from the query parameter.
Route-aware page tests web/src/pages/ProvidersPage.test.tsx, web/src/pages/ModelsPage.test.tsx	Tests add router context and verify provider links and URL-based model filtering.
Dashboard bundle and entrypoint src/gateway/static/dashboard/index.html, src/gateway/static/dashboard/assets/index-DPSOW7kR.js	The dashboard points to a refreshed hashed bundle containing updated React, React DOM, React Router, overlay styles, and secret-example templates.

Estimated code review effort: 3 (Moderate) | ~20 minutes

Possibly related PRs

• mozilla-ai/otari#227: Related dashboard Models/Providers UI and routing changes.
• mozilla-ai/otari#297: Related provider dashboard runtime and routing behavior.
• mozilla-ai/otari#347: Related ProvidersPage provider-row rendering changes.

Suggested reviewers: khaledosman

🚥 Pre-merge checks | ✅ 3 | ❌ 2

❌ Failed checks (2 warnings)

Check name	Status	Explanation	Resolution
Docstring Coverage	⚠️ Warning	Docstring coverage is 0.00% which is insufficient. The required threshold is 80.00%.	Write docstrings for the functions missing them to satisfy the coverage threshold.
Title check	⚠️ Warning	The title is relevant, but it uses feat(dashboard): instead of the required feat: Conventional Commit prefix.	Change the prefix to an allowed Conventional Commit form, e.g. feat: link provider name to filtered models page.

✅ Passed checks (3 passed)

Check name	Status	Explanation
Linked Issues check	✅ Passed	The PR satisfies #349 by linking providers to the filtered Models page and initializing the filter from the query parameter.
Out of Scope Changes check	✅ Passed	The changes stay focused on provider-to-model navigation and the required dashboard bundle rebuild.
Description check	✅ Passed	The description matches the template and includes the required sections, issue reference, tests, and AI usage details.

✨ Finishing Touches

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch fix/provider-click-navigates-to-filtered-models

✨ Simplify code

• Create PR with simplified code
• Commit simplified code in branch fix/provider-click-navigates-to-filtered-models

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands.}

[Copilot]

Pull request overview

Adds a dashboard UX shortcut so selecting a provider in the Providers page deep-links to the Models page with that provider pre-selected via a ?provider= query parameter, matching existing query-param driven flows.

Changes:

• Providers table provider names are now links to /models?provider=<instance>.
• Models page reads the provider query parameter on initial render to seed the provider filter.
• Adds/updates dashboard unit tests to cover link generation and query-param initialization; rebuilds the bundled dashboard index.html asset reference.

Reviewed changes

Copilot reviewed 5 out of 7 changed files in this pull request and generated 1 comment.

Show a summary per file

File	Description
web/src/pages/ProvidersPage.tsx	Renders provider instances as router links pointing at the Models page with ?provider=.
web/src/pages/ProvidersPage.test.tsx	Wraps page in a router and asserts provider links include the expected href.
web/src/pages/ModelsPage.tsx	Initializes the provider filter from the provider query parameter.
web/src/pages/ModelsPage.test.tsx	Adds a test that verifies the provider filter is pre-populated from ?provider=.
src/gateway/static/dashboard/index.html	Updates the hashed JS bundle reference after rebuilding the dashboard.

[khaledosman]

LGTM. encodeURIComponent on the instance, token-based hover styling, and the useState(searchParams.get(...)) mount-read all match existing patterns (?target= on AliasesPage, NavLink in AppShell). Tests cover both the link and the URL-driven filter. No changes requested.

Review created by Claude Code.