[JENKINS-60866] Remove inline JS from configure-common

[daniel-beck]

See JENKINS-60866.

This wasn't really straightforward:

• One fairly central form validation method took a displayUrl argument instead of value. When fixing that up, I kept the old argument for compatibility.
• Add support for passing arbitrary additional parameters to form validation by defining data-checkurlextra-KEY attributes, whose value is the value being sent. This can be an alternative to additional form elements like done in https://github.com/jenkinsci/jenkins/pull/6859

I'm not really happy with how this went, so alternative suggestions are welcome.

Proposed changelog entries

• Developer: Allow passing additional parameters to modern (non-JS) form validation using data-checkurlextra-KEY attributes.

Proposed upgrade guidelines

N/A

Submitter checklist

• [ ] (If applicable) Jira issue is well described
• [ ] Changelog entries and upgrade guidelines are appropriate for the audience affected by the change (users or developer, depending on the change) and are in the imperative mood. Examples
  • Fill-in the Proposed changelog entries section only if there are breaking changes or other changes which may require extra steps from users during the upgrade
• [ ] Appropriate autotests or explanation to why this change has no tests
• [ ] New public classes, fields, and methods are annotated with @Restricted or have @since TODO Javadoc, as appropriate.
• [ ] New deprecations are annotated with @Deprecated(since = "TODO") or @Deprecated(forRemoval = true, since = "TODO") if applicable.
• [ ] For dependency updates: links to external changelogs and, if possible, full diffs

Desired reviewers

@mention

Maintainer checklist

Before the changes are marked as ready-for-merge:

• [ ] There are at least 2 approvals for the pull request and no outstanding requests for change
• [ ] Conversations in the pull request are over OR it is explicit that a reviewer does not block the change
• [ ] Changelog entries in the PR title and/or Proposed changelog entries are accurate, human-readable, and in the imperative mood
• [ ] Proper changelog labels are set so that the changelog can be generated automatically
• [ ] If the change needs additional upgrade steps from users, upgrade-guide-needed label is set and there is a Proposed upgrade guidelines section in the PR title. (example)
• [ ] If it would make sense to backport the change to LTS, a Jira issue must exist, be a Bug or Improvement, and be labeled as lts-candidate to be considered (see query).

[github-actions[bot]]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[github-actions[bot]]

Please take a moment and address the merge conflicts of your pull request. Thanks!

[mawinter69]

How about just adding a doCheckDisplayNameOrNull method in the AbstractProjectDecriptor in a similar way as folders are doing it?

public FormValidation doCheckDisplayNameOrNull(@AncestorInPath AbstractProject project, @QueryParameter String value) {
  return Jenkins.get().doCheckDisplayName(value, project.getName());
}

Alternatively allow parameter renaming in the checkDependsOn via so you can write

  checkUrl="${rootURL}/checkDisplayName" checkDependsOn="displayName:displayNameOrNull jobName:name"

[daniel-beck]

How about just adding a doCheckDisplayNameOrNull method in the AbstractProjectDecriptor in a similar way as folders are doing it?

I like this suggestion, assuming it works out as well as I hope. Thanks! I will take a look when I have some time (or feel free to propose an alternative to this PR yourself).

[daniel-beck]

Superseded by #8866.