Repository navigation
fix(site): use the active version on the parameters page when it is required - #30906
jeremyruppel wants to merge 1 commit into
Conversation
aslilac
left a comment
There was a problem hiding this comment.
I already fixed this to send the user to this page with the correct version id specified. why do we need this?
|
the decision log on #30660 says:
this PR fixes that first part. going directly to Settings → Parameters from the sidebar doesn't pass a template version id, so the page is still read-only there. with this change, users who can't change versions always get the active version on this page, whatever the query string says |
…equired Users who cannot change template versions on a template that requires the active version could only edit parameters when the page was opened with ?templateVersionId=<active>. Opening it from the settings sidebar showed a read-only form, leaving them stuck when the new version rejected a saved value. The page now always targets the active version for these users. Fixes #19676
1b7de3f to
c4fc390
Compare
|
I'm not a fan of shadowing an explicitly specified value. this could be fine as a default but I don't think it should override. |
| // The target version depends on permissions. | ||
| if (!permissionsLoaded) return; |
There was a problem hiding this comment.
I don't like adding another condition here. why not just leave templateVersionId unresolved until permissions is set so that it falls through to the early return immediately after this?
Fixes #19676. Fixes DASH-105.
Follow-up to #30660. That PR unlocked the parameters form for users who cannot change template versions, but only when the page was opened with
?templateVersionId=<active version>. Opening it any other way (Settings → Parameters, the build parameters popover, a bookmark) still showed a read-only form against the old version, so a member whose saved value the new version rejects could not fix it there.The page now always targets the template's active version for these users, whatever the URL says. Builds on any other version are rejected for them anyway. #30660's check in the view already unlocks the form on the active version, so the view is unchanged.
The parameters websocket now waits for permissions to load, since they decide which version it connects to. Switching versions after connecting would drop the new socket's initial response.
Decisions and notes
WorkspaceParametersPage.tsxso every entry point is covered, instead of adding?templateVersionIdto each link.RequireActiveVersionBlocked*stories. The state they captured (a member locked out on this page) can no longer happen.disabledcheck in the view can no longer trigger for these users. Left in place to keep this diff small.Testing
?templateVersionIdon an outdated workspace whose template requires the active version. The websocket connects once, to the active version, and submitting sends the active version. Fails without the fix.tsc, and knip are clean.require_active_version, a member workspace built on v1 withsize=large, v2 removeslarge. Settings → Parameters was read-only before the fix and editable after; updating built the workspace on v2.Generated by Coder Agents on behalf of @jeremyruppel.