Job has some fairly complex infrastructure for handling renames:
- the special textbox in configure.jelly
- the handling in doConfigSubmit, including ProjectNamingStrategy integration, Apply vs. Save logic (including the tricky
JENKINS-17401fix), and the redirect - rename.jelly (and rename.properties)
- doDoRename, with more checks and redirects
Reimplementing all this in another item type (such as Folder) is rather painful, involving a lot of duplicated code and thus an inability to fix a bug once in one placeāor pick a different implementation, such as using a JavaScript dialog like we now use for deletion and other actions requiring confirmation.
This code should be pulled up into AbstractItem for easy reuse, with some hooks for domain-specific validation (such as Job.isBuilding).
- is related to
-
JENKINS-17401 Renaming a job and clicking 'Apply' shows an empty 'Error' pop-over window
-
- Resolved
-
-
JENKINS-18649 Renaming jobs should be a separate permission from configuring
-
- Open
-
- links to
[JENKINS-22936] Move rename infrastructure from Job to AbstractItem
Labels | Original: api dry | New: api dry folders |
Link |
New:
This issue is related to |
Link | New: This issue is related to SECURITY-128 [ SECURITY-128 ] |
Link | New: This issue is related to JENKINS-18649 [ JENKINS-18649 ] |
Workflow | Original: JNJira [ 155082 ] | New: JNJira + In-Review [ 179008 ] |
Also handling of possibly distinct display names (displayNameOrNull, AbstractProject/configure-common.jelly) would logically belong in the same place.