Propagate readOnlyMode into all dropdownDescriptorSelector fragments in core

[Racknaraock]

Part of JENKINS-12548 "Read-only system configuration browsing" (#12412), the JEP-224 effort to make config/admin pages properly disable themselves for users with Item.EXTENDED_READ/Overall.SYSTEM_READ but without CONFIGURE/ADMINISTER.

No individual JENKINS issue exists yet for this specific gap (a generic core issue, not previously filed); per CONTRIBUTING.md this is treated as a minor improvement/bugfix that doesn't require one.

Background / how this was found

f:dropdownDescriptorSelector (lib/form/dropdownDescriptorSelector.jelly) renders the currently-selected option inline, but defers every other option's config.jelly/config.groovy via l:renderOnDemand, fetched later through a separate AJAX/stapler-proxy call. renderOnDemand only forwards variables named in its capture attribute into that later render. readOnlyMode (the variable pages like Job/configure.jelly set to drive read-only rendering) was never in any of these capture lists, so a viewer with only Item.EXTENDED_READ/Overall.SYSTEM_READ could get back a fully editable-looking fragment for any option other than the currently-selected one — even though every other field on the same page correctly disables.

This was first discovered and fixed for the "SCM Checkout Strategy" dropdown on Job/configure.jelly while working on cloudbees-folder-plugin#747 (JENKINS-62218, read-only folder configuration) — that PR originally carried a folder-specific version of this same fix, which was reverted there once it became clear the root cause lives in core and affects every Job configure page, not just folders. @jtnord's review on that PR confirmed this "[w]ould appear to be a generic bug in Jenkins core and would affect all users of dropdownDescriptorSelector across the project," which prompted auditing every *.jelly/*.groovy usage of the tag in core/ to find and close the remaining instances rather than fixing only the one that was originally reported.

What this PR fixes

Adds capture="readOnlyMode" (or capture: "readOnlyMode" in Groovy views) to every remaining f:dropdownDescriptorSelector call site whose containing page actually sets readOnlyMode:

• HudsonPrivateSecurityRealm/config.jelly — Password Complexity Rule
• DelegatingComputerLauncher/config.jelly, DumbSlave/configure-entries.jelly — agent Launch method, Availability/retention strategy
• Maven/config.jelly — Settings file, Global Settings file (build-step config)
• GlobalFingerprintConfiguration/config.jelly — Fingerprint Storage Engine
• BuildDiscarderProperty/config-details.jelly, SimpleGlobalBuildDiscarderStrategy/config.jelly — Discard old builds strategy, at both the per-job and global-default nesting levels
• GlobalMavenConfig/config.groovy — default settings/global settings provider
• ViewsTabBar/GlobalConfigurationImpl/config.groovy — Views Tab Bar
• GlobalCrumbIssuerConfiguration/config.groovy — Crumb Issuer
• GlobalSecurityConfiguration/index.groovy — Security Realm, Authorization, Markup Formatter selectors on "Manage Jenkins > Security" (reachable with only Overall.SYSTEM_READ)

hudson/model/MyViewsProperty/config.jelly (Views Tab Bar on a user's own account page) was deliberately left out: that page (UserPropertyCategoryPreferencesAction) is gated by Jenkins.ADMINISTER checked against the nearest AccessControlled ancestor, which resolves to the target User, and User#getACL() always grants a non-anonymous user full control of themselves regardless of any Jenkins-wide role. So this page is only ever reachable by the account owner (full access, by design) or a real instance administrator -- there is no partial/read-only view of someone else's account settings, and readOnlyMode is never set anywhere in its render chain. Not an instance of this bug.

A note on GlobalSecurityConfiguration specifically, since it's a more sensitive page than the others: before including it here, I verified this is not a privilege-escalation vector. GlobalSecurityConfiguration#configure() calls j.checkPermission(Jenkins.ADMINISTER) unconditionally as its first line, before any submitted JSON is read, so a forged configSubmit POST from a SYSTEM_READ-only user is rejected server-side (AccessDeniedException3: ... is missing the Overall/Administer permission) regardless of what the UI rendered; the Save/Apply buttons are also only rendered inside l.isAdmin(). The lazily-rendered fragment itself never carries live secrets either, since dropdownDescriptorSelector renders non-selected options with instance=null. The same double gate (checkPermission(CONFIGURE) in doConfigSubmit) exists for the Job/Computer-scoped sites above, so all of these are the same severity class: a read-only-mode UI/UX gap, not a write-path vulnerability.

Testing done

Added two regression tests:

• test/src/test/java/jenkins/scm/SCMCheckoutStrategyReadOnlyModeTest.java — registers a throwaway SCMCheckoutStrategy with a real editable field, loads a Job's configure page as a viewer with only Item.READ+Item.EXTENDED_READ, triggers the same client-side renderOnDemand() JS a browser fires when switching the dropdown, and asserts the resulting fragment renders as the standard read-only N/A placeholder rather than an editable <input>. Verified manually that this test fails (editable <input name="_.value">) against the pre-fix config-scm.jelly and passes (read-only placeholder) against the fix.
• test/src/test/java/hudson/security/GlobalSecurityConfigurationReadOnlyModeTest.java — same pattern, covering the architecturally distinct Groovy-view/SYSTEM_READ path via a throwaway AuthorizationStrategy.

The other 8 call sites apply the identical one-line change against the identical capture/renderOnDemand mechanism exercised by both tests above, but don't have their own dedicated regression test; happy to add more if reviewers want per-site coverage.

Screenshots (UI changes only)

Nothing changes visually for users who already have CONFIGURE/ADMINISTER. For a viewer with only Overall.SYSTEM_READ, captured on the "Password Complexity Rule" dropdown (HudsonPrivateSecurityRealm/config.jelly) as a representative example -- same mechanism as the rest of this PR.

Before: Minimum password length renders as a live <input type="number" value="8">, and the four Require at least one ... checkboxes have no disabled attribute at all.

After: Minimum password length renders as <pre class="jenkins-readonly">8</pre> (the standard core read-only placeholder), and all four checkboxes carry disabled="true".

Proposed changelog entries

• Fix several dropdownDescriptorSelector-based configuration fields (SCM Checkout Strategy on Job pages, agent launch method/retention strategy, Maven settings providers, fingerprint storage engine, discard-old-builds strategy, views tab bar, crumb issuer, password complexity rule, Security Realm/Authorization/Markup Formatter on the Security page) not respecting read-only mode for viewers with Item.EXTENDED_READ/Overall.SYSTEM_READ

Proposed changelog category

/label bug

Proposed upgrade guidelines

N/A

Submitter checklist

• The issue, if it exists, is well-described. (No individual issue filed; described above and linked to epic JENKINS-12548 / [JENKINS-12548] Read-only system configuration browsing #12412.)
• The changelog entry is appropriate for the audience affected (users) and in the imperative mood.
• There is automated testing (see Testing done).
• New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadocs, as appropriate. (N/A — no new public API.)
• New deprecations are annotated. (N/A — no deprecations.)
• UI changes do not introduce CSP regressions (attribute-only change to existing tags, no new/changed JS).
• For dependency updates... (N/A.)
• For new APIs and extension points... (N/A.)

Desired reviewers

@jenkinsci/core-pr-reviewers

[timja]

Screenshots are required for any visual change. Please demonstrate what it looks like for users with read only access.

[jtnord]

rather than change all callers I was suggesting that propagating readOnlyMode should be done always in the taglib. That is it should not need changes across the ecosystem for any page showing a readonly mode using dropdownDescriptorSelector

[jtnord]

rather than change all callers I was suggesting that propagating readOnlyMode should be done always in the taglib. That is it should not need changes across the ecosystem for any page showing a readonly mode using dropdownDescriptorSelector

[Racknaraock]

You're right, thanks — done in 061162e.

[Racknaraock]

Screenshots are required for any visual change. Please demonstrate what it looks like for users with read only access.

@timja

I've only included one of the screenshots because, based on jtnord's comments, the changes apply across the entire structure. Let me know if this is okay or if you need all the screenshots of the affected components.