Add SaveAllJobsAction to save all jobs in folder after copy

[MalyalaKarthik66]

Summary

This PR introduces a SaveAllJobsAction that allows saving all jobs in a folder after copying, improving usability and preventing unsaved job issues.

Implementation

• Added SaveAllJobsAction.java using TransientActionFactory
• Added index.jelly for UI button
• Added unit tests for the new action
• Fixed form post URL to avoid 404 errors

Testing

• Verified manually via local Jenkins
• mvn clean test passes with no failures

Fixes JENKINS-20003

[rsandell]

gratuitous import

[rsandell]

gratuitous whitespace

[MalyalaKarthik66]

SaveAllJobsAction Feature – Demonstration & Usage:

This PR implements SaveAllJobsAction (for JENKINS-20003), which lets users conveniently save all jobs in a folder.

You can save all jobs inside a folder in three convenient ways:
1.During folder configuration:
Click the dropdown in the configuration view and select Save All Jobs to immediately save all jobs and the folder itself.

2.Within the folder sidebar:
Open any folder and use the Save All Jobs button in the left sidebar for one-click saving of all jobs.

3.From the dashboard (home):
On the Jenkins home page, next to the folder name, click the ▼ dropdown. You’ll see Save All Jobs listed among available actions—clicking it instantly saves all jobs in the chosen folder.

These options provide flexible access and ensure no job changes are lost.

Technical details & Code highlights:

• The code uses a TransientActionFactory pattern to inject the new action into folder views.
• UI is wired up with Jelly and tested working as shown in the images.
• All automated tests pass and manual verification confirms the expected behavior.

Let me know if further screenshots or information would be helpful.
Looking forward to your feedback and review!

[rsandell]

I don't think this is such a good idea since it will show up on all folder types including those where it makes no sense, such as calculated folders like MultiBranch et al.

[MalyalaKarthik66]

Thanks for the valuable feedback! I agree that showing the "Save All Jobs" action on every folder type could lead to confusion, especially for calculated folders like MultiBranch.
To address this, I plan to implementation so that the action only appears on standard folders where manual saving is meaningful. For other folder types, such as MultiBranch or calculated folders, the action will be hidden.

Please let me know if you have any suggestions on the best way to detect and filter folder types.

[jglick]

This does not seem like a good UX. I think it would be better to step back and study the original reason for disabling a job when it was copied, which is in core I think, an ancient part of Hudson Jenkins. Is this still relevant today? There is no such behavior when using configuration-as-code, for example. If people really want to do that I think it would be preferable for them to disable the original, then copy, then reënable the original. https://issues.jenkins.io/browse/JENKINS-27735 has some related ideas.

[jtnord]

This does not seem like a good UX. I think it would be better to step back and study the original reason for disabling a job when it was copied, which is in core I think, an ancient part of Hudson Jenkins. Is this still relevant today? There is no such behavior when using configuration-as-code, for example. If people really want to do that I think it would be preferable for them to disable the original, then copy, then reënable the original. https://issues.jenkins.io/browse/JENKINS-27735 has some related ideas.

Note I tried copying a folder with a job (FreeStyle) in it and the job in the copied folder was not marked as disabled in the UI. Its not buildable, but it was enabled. As such I agree with jglick that the UX is just confusing, adding this action does not improve matters and makes things more confusing (why would you need to save all jobs recursively via the UI as Jenkins saves things when you make changes, and this action would imply wrongly things can get out of sync without feedback).

irrespective of the UX, there is also no permission checks (you may be able to see a job but not save it, or you may not even able to see jobs in a folder!), and the action is suspectable to CSRF checks as it is not restricted to HTTP POST.

[MalyalaKarthik66]

Thank you for the feedback and for highlighting the diverse needs of Jenkins users.
After considering the discussion, I agree that most users might not need jobs to be automatically disabled or enabled after copying. Therefore, instead of enforcing a fixed behavior for everyone, I propose adding a global (configurable) option, such as a system property or an admin setting (e.g., -Djenkins.copyJobs.autoEnable=true).
With this toggle:Jenkins administrators can decide whether copied jobs should be enabled or disabled by default, based on their workflow and organizational policies.The default could be set to the safest/common preference, with clear documentation so users can change it as needed.

This would preserve backward compatibility for existing behavior, while giving flexibility to users who prefer automatic saving without manual actions.

[jglick]

System properties are not great either. On what basis would an “administrator” make such a decision? I am more inclined to just delete this weird enable-after-save behavior.