Users who wouldn't be trusted (to not break things) could be trusted to enable/disable jobs otherwise configured elsewhere, so this can make some sense (similar to the rename permission I requested somewhere to prevent users who are allowed to configure from renaming as they please which could e.g. break Role Strategy).
FWIW I often get requests like 'disable the nightly build for this release' from users that could do it themselves, except I don't want to give them Job/Configure.
+1, we have the same problem as described by Daniel Beck. Users need to disable/enable nightly jobs quite often, it would be nice if we could allow them to do so, without them being able to touch other settings.
+1. Its good to have flexibility to give users (in our case testing team members) to disable or enable the test jobs but not allow them to make any changes to Job configuration.
Daniel Beck, what solution you use for this issue as a workaround? One way I see it could be another Jenkins job which disables nightly build. Not so nice solution.
I agree that allowing users to enable/disable jobs is fundamentally different from a user perspective than allowing them to modify arbitrary configuration options in the job itself. Whether this is easy to implement / separate under the hood or not is something else entirely of course, however it would be beneficial to users if it could be done.
+1, same use cases. I found this ticket when googling to find out how others made it happen when I saw that the matrix-based security grid doesn't break it out between enable/disable and other configure changes. Would be great to have it do so.