Loading
Fix stale redirect anchors on admin settings forms
Summary
Fixed 3 admin settings forms where "Save changes" buttons redirected to anchors that matched no HTML ids. This caused the page to stay at the top instead of scrolling to the edited section.
- Jira Connect settings: Changed anchor from
js-jira-connect-application-id-settingstojs-jira_connect-settingsto match the actual section id. - Security txt settings: Changed anchor from
js-security-txt-settingstojs-security-txt-settingto match the actual section id (corrected plural to singular). - PIPL compliance settings: The section had a duplicate id copied from the unrelated Security policies section above it. Gave it a unique id
js-enforce-pipl-compliance-settingsand testidadmin-enforce-pipl-compliance-settingsto match the form's existing anchor.
How this was found
A repo-wide audit compared every self-referencing form redirect anchor in app/views/admin and ee/app/views/admin to the actual HTML ids in those files. Three anchors had no matching ids anywhere. This is the same class of bug as the earlier fix in merge request !250432 (merged) (stale anchor on the admin CI/CD settings page).
Verification
- Loaded the admin General settings page locally.
- Submitted the Jira Connect and Security txt forms.
- Confirmed the resulting URL and scroll position land on the correct section after each save, both before and after the fix.
- Could not verify the PIPL compliance fix locally (the section only renders on Gitlab.com when
pipl_complianceis enabled). Confirmed the duplicate-id bug by direct code inspection — the same id string appears twice in the same file, which is invalid HTML.
This is a minimal, mechanical fix with no refactors or behavior changes beyond correcting the anchors and ids.
References
- Same bug class as !250432 (merged) (fixed the original stale anchor on the admin CI/CD settings page)
- That bug was originally found in !250432 (comment 3739150815)
- The CI/CD anchor drifted from its section id in 6ea284f5, which migrated the section to
Layouts::SettingsBlockComponentand renamed its id without updating the form's redirect anchor in a separate partial. The 3 fixes here are the same failure mode found by auditing every other admin settings form for the same drift.
Edited by Miguel Rincon