Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-18649

Renaming jobs should be a separate permission from configuring

    • Icon: New Feature New Feature
    • Resolution: Unresolved
    • Icon: Major Major
    • core

      Renaming jobs

      • can cause wrong behavior in some plugins (job-specific permissions in Role Strategy due to design or favorites in Favorites plugin due to brokenness come to mind)
      • can be an expensive operation when many relationships between jobs are affected (upstream/downstream relations, trigger parameterized buildplugin, copy artifacts plugin, ...)
      • breaks bookmarks and links in documentation (external wiki, or even view descriptions) and notification emails

      All of these are possible reasons that administrators might want to prevent users from renaming jobs while still allowing them to configure.

      Job names are also mostly unrelated to a job's content, i.e. there's usually little relation between the scripts or programs a job calls (and the act of configuring this) and how the job is named in Jenkins.

      Therefore the new permission Job/Rename (or Item/Rename) should be introduced, and renaming items should require that permission instead of Configure.

      MOVE permission in Folders 3.x and Folders Plus 2.x plugins is its own permission as well, and could be combined with a new RENAME permission, as they basically do the same thing.

          [JENKINS-18649] Renaming jobs should be a separate permission from configuring

          Daniel Beck added a comment -

          JENKINS-18678 could be circumvented by just taking away users' permission to rename while keeping the permission to configure jobs.

          Daniel Beck added a comment - JENKINS-18678 could be circumvented by just taking away users' permission to rename while keeping the permission to configure jobs.

          Aaron Searle added a comment -

          Jenkins used to have this feature but it was removed some time ago (not sure why), which in turn caused problems with our authorisation plugin. I agree that job renames should be a separate permission as the name represent's the job's identity rather than it's configuration.

          Aaron Searle added a comment - Jenkins used to have this feature but it was removed some time ago (not sure why), which in turn caused problems with our authorisation plugin. I agree that job renames should be a separate permission as the name represent's the job's identity rather than it's configuration.

          Scott Rahner added a comment -

          This is a big issue for us at Dow Jones where central teams create and manage jobs, folders, etc but the app teams own the jobs content. When they rename jobs it causes all sort of havok with plugins, apis, reports, etc

          Scott Rahner added a comment - This is a big issue for us at Dow Jones where central teams create and manage jobs, folders, etc but the app teams own the jobs content. When they rename jobs it causes all sort of havok with plugins, apis, reports, etc

          Jesse Glick added a comment -

          As noted in JENKINS-22936, the current implementation is wrong anyway since CREATE is being checked on an Item when it ought to be checked on an ItemGroup according to its defined ITEM_GROUP and all of its other check calls.

          Jesse Glick added a comment - As noted in  JENKINS-22936 , the current implementation is wrong anyway since CREATE is being checked on an Item when it ought to be checked on an ItemGroup according to its defined ITEM_GROUP and all of its other check calls.

            Unassigned Unassigned
            danielbeck Daniel Beck
            Votes:
            4 Vote for this issue
            Watchers:
            5 Start watching this issue

              Created:
              Updated: