fix(forms): make :project specific fields searchable - #121048
Conversation
github-actions
Bot
added
the
Scope: Frontend
![cursor[bot]](https://avatars.githubusercontent.com/in/1210556?s=60&v=4){kind=small}
There was a problem hiding this comment.
Cursor Bugbot has reviewed your changes and found 2 potential issues.
❌ Bugbot Autofix is OFF. To automatically fix reported issues with cloud agents, enable autofix in the Cursor dashboard.
Want reviews to match your repository better? Bugbot Learning can learn team-specific rules from PR activity. A team admin can enable Learning in the Cursor dashboard.
Reviewed by Cursor Bugbot for commit b543614. Configure here.
| } | ||
| if (route.includes(':projectId')) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Field hash lost after project picker
Medium Severity
Including :projectId routes puts field entries with a hash deep-link through ProjectSettingsLayout, which calls navigateTo with only location.pathname. That drops the hash, so after the user picks a project they land on the settings page without scrolling to or focusing the matched field.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit b543614. Configure here.
| } | ||
| if (route.includes(':projectId')) { | ||
| return false; | ||
| } |
There was a problem hiding this comment.
Ambiguous project section titles
Medium Severity
titleFromRoute only strips :orgId / account, so every newly included project route still starts with projects and becomes a section titled Projects. Distinct pages such as alerts, filters, and ownership all share that label, and the same string is reused in field keywords.
Additional Locations (1)
Reviewed by Cursor Bugbot for commit b543614. Configure here.
2 participants
Project-scoped form fields (routes containing
:projectId) are now included inthe settings command palette search. Previously
isSettingsRoutedropped anyfield whose route had a
:projectIdplaceholder, so fields like the Seer"Handoff to Agent" option never surfaced — searching for their label returned
nothing, even though the extracted registry entry was correct.
The
:projectIdexclusion existed because the generatedtoonly resolves:orgId, leaving:projectIdliteral in the path. That turns out to be fine:navigating to such a route lands on
ProjectSettingsLayout, which detects the:projectIdplaceholder and opens the context picker for the user to choose aproject.
:teamIdand:appIdremain excluded since their layouts don't havethat redirect.
Refs DE-1491