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

Add "Job Create" permission to project roles

    XMLWordPrintable

    Details

    • Similar Issues:

      Description

      Currently, the "role strategy" plugin allows you to restrict access to jobs, based on a job-name pattern, using "Project roles". The following permissions are available:

      Delete Configure Read Discover Build Workspace Cancel

      However, I can't give a user permissions to create only jobs that match a certain job-name pattern. "Job Create" privilege is a "Global Role", not a "Project Role".
      Can this be fixed?

        Attachments

          Issue Links

            Activity

            Hide
            integer Kanstantsin Shautsou added a comment -

            The same issue.

            Show
            integer Kanstantsin Shautsou added a comment - The same issue.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I've updated the description somewhere, but have not managed to find such update

            Regexp-driven "Create" permissions in jobs and slaves require mechanisms, which are not available within the current Jenkins core version.
            The workaround is to create a job name verifier extension ("Restrict project naming"), which takes the data from the strategy and enforces it for users.

            I won't be able to handle this feature request soon.
            Feel free to contribute.

            Show
            oleg_nenashev Oleg Nenashev added a comment - I've updated the description somewhere, but have not managed to find such update Regexp-driven "Create" permissions in jobs and slaves require mechanisms, which are not available within the current Jenkins core version. The workaround is to create a job name verifier extension ("Restrict project naming"), which takes the data from the strategy and enforces it for users. I won't be able to handle this feature request soon. Feel free to contribute.
            Hide
            integer Kanstantsin Shautsou added a comment - - edited

            After fix JENKINS-23127 it will be possible to have "role based project naming" extension, but it will require new core or someway to have it optionally. Or assign roles may have "create" checkboxes that will work only on new core and with enabled "project naming".
            So checkbox tip will say "only with project naming strategy", project naming will say "only on core >XXXX".

            Show
            integer Kanstantsin Shautsou added a comment - - edited After fix JENKINS-23127 it will be possible to have "role based project naming" extension, but it will require new core or someway to have it optionally. Or assign roles may have "create" checkboxes that will work only on new core and with enabled "project naming". So checkbox tip will say "only with project naming strategy", project naming will say "only on core >XXXX".
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Agreed.
            You can just hide the permission from Web UI according to the core version comparison. I do such thing in Dynamic Search View Plugin (see https://github.com/jenkinsci/dynamic-search-view-plugin/commit/bf6869cc36f1dfc7e258a750a596c55b65acfd80)

            Show
            oleg_nenashev Oleg Nenashev added a comment - Agreed. You can just hide the permission from Web UI according to the core version comparison. I do such thing in Dynamic Search View Plugin (see https://github.com/jenkinsci/dynamic-search-view-plugin/commit/bf6869cc36f1dfc7e258a750a596c55b65acfd80 )
            Hide
            scm_issue_link SCM/JIRA link daemon added a comment -

            Code changed in jenkins
            User: Kanstantsin Shautsou
            Path:
            src/main/java/com/michelin/cio/hudson/plugins/rolestrategy/RoleBasedAuthorizationStrategy.java
            src/main/java/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy.java
            src/main/resources/com/michelin/cio/hudson/plugins/rolestrategy/Messages.properties
            src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/config.groovy
            src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/config.properties
            src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/help.html
            http://jenkins-ci.org/commit/role-strategy-plugin/d5178f39de2f2e453f98b4637248bcfec77e8de4
            Log:
            [FIXED JENKINS-19934] Job create permission for RoleBasedProjectNamingStrategy.

            Show
            scm_issue_link SCM/JIRA link daemon added a comment - Code changed in jenkins User: Kanstantsin Shautsou Path: src/main/java/com/michelin/cio/hudson/plugins/rolestrategy/RoleBasedAuthorizationStrategy.java src/main/java/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy.java src/main/resources/com/michelin/cio/hudson/plugins/rolestrategy/Messages.properties src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/config.groovy src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/config.properties src/main/resources/org/jenkinsci/plugins/rolestrategy/RoleBasedProjectNamingStrategy/help.html http://jenkins-ci.org/commit/role-strategy-plugin/d5178f39de2f2e453f98b4637248bcfec77e8de4 Log: [FIXED JENKINS-19934] Job create permission for RoleBasedProjectNamingStrategy.
            Hide
            mwebber Matthew Webber added a comment -

            "Job Create" can now be selected (or de-delected) for a jobname pattern in "Manage and Assign Roles" --> "Manage Roles" --> "Project roles".

            However, this doesn't appear to have aby effect:

            • If a user has a global role with "Job Create" then they can create any jobname.
            • If the user does not have such a global role, they cannot create any jobs. In fact, the "New View" link to create a job is not even displayed.

            Project roles are ignored.

            Is there some change in Jenkins core that needs to be made to actually use the "Project roles" "Job Create" setting? If so, is there a Jira ticket for this, or does one need to be opened?

            Thanks

            Show
            mwebber Matthew Webber added a comment - "Job Create" can now be selected (or de-delected) for a jobname pattern in "Manage and Assign Roles" --> "Manage Roles" --> "Project roles". However, this doesn't appear to have aby effect: If a user has a global role with "Job Create" then they can create any jobname. If the user does not have such a global role, they cannot create any jobs. In fact, the "New View" link to create a job is not even displayed. Project roles are ignored. Is there some change in Jenkins core that needs to be made to actually use the "Project roles" "Job Create" setting? If so, is there a Jira ticket for this, or does one need to be opened? Thanks
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            1) As designed. Global roles override any project-specific permissions
            2) See https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin?focusedCommentId=73533281#comment-73533281 for configuration guidelines

            Show
            oleg_nenashev Oleg Nenashev added a comment - 1) As designed. Global roles override any project-specific permissions 2) See https://wiki.jenkins-ci.org/display/JENKINS/Role+Strategy+Plugin?focusedCommentId=73533281#comment-73533281 for configuration guidelines
            Hide
            mwebber Matthew Webber added a comment -

            >> Global roles override any project-specific permissions.
            Understood. My problem is when the user is not assigned to any global role.

            Here's the problem case:

            • The main Jenkins configuration has "Restrict project naming" on, with "Role-Based Strategy" selected.
            • I have a project role called "Controls-Administrator" with a jobname pattern of "Controls.*". The role has all job permissions set.
            • user xzl80115 is not assigned to any global role
            • user xzl80115 is assigned to project role "Controls-Administrator"

            In this case, I would expect that user xzl80115 could create jobs named something like "Controls_abc". However, the "New View" link to create a job is never displayed, and if the user manually enters the URL http://<jenkins>/newJob then he gets told he does not have permission to create any jobs.

            It may be relevant that users authenticate using the CAS plugin and the CAS 2.0 protocol.

            Show
            mwebber Matthew Webber added a comment - >> Global roles override any project-specific permissions. Understood. My problem is when the user is not assigned to any global role. Here's the problem case: The main Jenkins configuration has "Restrict project naming" on, with "Role-Based Strategy" selected. I have a project role called "Controls-Administrator" with a jobname pattern of "Controls.*". The role has all job permissions set. user xzl80115 is not assigned to any global role user xzl80115 is assigned to project role "Controls-Administrator" In this case, I would expect that user xzl80115 could create jobs named something like "Controls_abc". However, the "New View" link to create a job is never displayed, and if the user manually enters the URL http://<jenkins>/newJob then he gets told he does not have permission to create any jobs. It may be relevant that users authenticate using the CAS plugin and the CAS 2.0 protocol.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            What Jenkins Core version do you use?

            Show
            oleg_nenashev Oleg Nenashev added a comment - What Jenkins Core version do you use?
            Hide
            mwebber Matthew Webber added a comment -

            Sorry, I should have said. This is Jenkins 1.575, with Role Strategy Plugin 2.2.0. and CAS Plugin 1.1.2.

            Show
            mwebber Matthew Webber added a comment - Sorry, I should have said. This is Jenkins 1.575, with Role Strategy Plugin 2.2.0. and CAS Plugin 1.1.2.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Kanstantsin Shautsou, any updates?

            Show
            oleg_nenashev Oleg Nenashev added a comment - Kanstantsin Shautsou , any updates?
            Hide
            integer Kanstantsin Shautsou added a comment -

            AFAIR restrict project naming works when you entering project name after you opened "new project" link.

            Show
            integer Kanstantsin Shautsou added a comment - AFAIR restrict project naming works when you entering project name after you opened "new project" link.
            Hide
            integer Kanstantsin Shautsou added a comment -

            Please, provide info from http://<jenkins>/whoAmI under logged in xzl80115 user (part before cookies).

            Show
            integer Kanstantsin Shautsou added a comment - Please, provide info from http://<jenkins>/whoAmI under logged in xzl80115 user (part before cookies).
            Hide
            mwebber Matthew Webber added a comment -

            Sorry about the delay in reponding, Kanstantsin. I have recreated the problem; here's the data you need:

            • Running Jenkins 1.595, Role Strategy Plugin 2.2.0. and CAS Plugin 1.1.2.
            • The main Jenkins configuration has "Restrict project naming" on, with "Role-Based Strategy" selected.
            • I have a project role called "Dials-Administrator" with a jobname pattern of "(cctbx|dials|xia2).*". The role has all job permissions set.
            • user wra62962 is not assigned to any global role
            • user wra62962 is assigned to project role "Dials-Administrator"
            • user wra62962 cannot create a new job named e.g. cctbx-new, but should be able to.

            /whoAmI for wra62962

            Who Am I?
            Name:	wra62962
            IsAuthenticated?:	true
            Authorities:	•	"authenticated"
            Details:	
            toString:	org.jenkinsci.plugins.cas.spring.security.CasAuthentication@fc9b3225: Username: org.acegisecurity.userdetails.User@fc52b100: Username: wra62962; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: authenticated; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: authenticated Assertion: org.jasig.cas.client.validation.AssertionImpl@21427846 Credentials (Service/Proxy Ticket): ST-3984-9HEe7tcxOEIQJ5B5MXxd-cas01.example.org
            

            For comparison, here is another user who is assigned to a global role called "admin" (which is allowed to do "job create"), and that user can create jobs ok.

            Who Am I?
            Name:	bmn54829
            IsAuthenticated?:	true
            Authorities:	"authenticated"
            Details:	
            toString:	org.jenkinsci.plugins.cas.spring.security.CasAuthentication@fe49761d: Username: org.acegisecurity.userdetails.User@2738a00: Username: bmn54829; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: authenticated; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: authenticated Assertion: org.jasig.cas.client.validation.AssertionImpl@3abc9d02 Credentials (Service/Proxy Ticket): ST-3924-pDmuQxc9KY4DrMed6CBf-cas01.example.org
            
            Show
            mwebber Matthew Webber added a comment - Sorry about the delay in reponding, Kanstantsin. I have recreated the problem; here's the data you need: Running Jenkins 1.595, Role Strategy Plugin 2.2.0. and CAS Plugin 1.1.2. The main Jenkins configuration has "Restrict project naming" on, with "Role-Based Strategy" selected. I have a project role called "Dials-Administrator" with a jobname pattern of "(cctbx|dials|xia2).*". The role has all job permissions set. user wra62962 is not assigned to any global role user wra62962 is assigned to project role "Dials-Administrator" user wra62962 cannot create a new job named e.g. cctbx-new, but should be able to. /whoAmI for wra62962 Who Am I? Name: wra62962 IsAuthenticated?: true Authorities: • "authenticated" Details: toString: org.jenkinsci.plugins.cas.spring.security.CasAuthentication@fc9b3225: Username: org.acegisecurity.userdetails.User@fc52b100: Username: wra62962; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: authenticated; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: authenticated Assertion: org.jasig.cas.client.validation.AssertionImpl@21427846 Credentials (Service/Proxy Ticket): ST-3984-9HEe7tcxOEIQJ5B5MXxd-cas01.example.org For comparison, here is another user who is assigned to a global role called "admin" (which is allowed to do "job create"), and that user can create jobs ok. Who Am I? Name: bmn54829 IsAuthenticated?: true Authorities: "authenticated" Details: toString: org.jenkinsci.plugins.cas.spring.security.CasAuthentication@fe49761d: Username: org.acegisecurity.userdetails.User@2738a00: Username: bmn54829; Password: [PROTECTED]; Enabled: true; AccountNonExpired: true; credentialsNonExpired: true; AccountNonLocked: true; Granted Authorities: authenticated; Password: [PROTECTED]; Authenticated: true; Details: null; Granted Authorities: authenticated Assertion: org.jasig.cas.client.validation.AssertionImpl@3abc9d02 Credentials (Service/Proxy Ticket): ST-3924-pDmuQxc9KY4DrMed6CBf-cas01.example.org
            Hide
            danielbeck Daniel Beck added a comment -

            This is simply not possible, as the permission to create items is given by the future item's container independent of the name of what you will create. You get access to the 'Create Item' page before having to specify a name, after all.

            Show
            danielbeck Daniel Beck added a comment - This is simply not possible, as the permission to create items is given by the future item's container independent of the name of what you will create. You get access to the 'Create Item' page before having to specify a name, after all.
            Hide
            mwebber Matthew Webber added a comment - - edited

            This is simply not possible, as the permission to create items is given by the future item's container independent of the name of what you will create. You get access to the 'Create Item' page before having to specify a name, after all.

            Of course! Thanks. That explains what I see. There is a bug in the current handling, but it's not what I originally reported.

            Here's what I did:

            • Created a global role called "job-create", which has ONLY the "Job / Create" (and "Overall / Read") privileges.
            • Assigned user X to that global role.
            • Created a project role called "Dials-Administrator" with a jobname pattern of "(cctbx|dials|xia2).*". The role has all job permissions set.
            • Assigned user X to that project role.

            What I wanted to happen:

            • User X could create a job whose name matched "(cctbx|dials|xia2).*"
            • User X could not create a job whose name did not match "(cctbx|dials|xia2).*"

            What actually happend:

            • User X could see and click on "New Item"
            • User X could successfully create a new job whose name matched "(cctbx|dials|xia2).*"
            • User X attempted to created a new project with the name "dummy job"
            • User X got
              HTTP ERROR 404
              Problem accessing /job/dummy%20job/configure. Reason: Not Found
              

            It looks like the user was prevented creating a job with a name they are not authorised to access. However, Jenkins actually went ahead and created the job (it's visible in the "All" tab), so it looks like the authorisation test is being done too late.

            A friendlier error message would be nice, as well.

            Hope that helps.

            Show
            mwebber Matthew Webber added a comment - - edited This is simply not possible, as the permission to create items is given by the future item's container independent of the name of what you will create. You get access to the 'Create Item' page before having to specify a name, after all. Of course! Thanks. That explains what I see. There is a bug in the current handling, but it's not what I originally reported. Here's what I did: Created a global role called "job-create", which has ONLY the "Job / Create" (and "Overall / Read") privileges. Assigned user X to that global role. Created a project role called "Dials-Administrator" with a jobname pattern of "(cctbx|dials|xia2).*". The role has all job permissions set. Assigned user X to that project role. What I wanted to happen: User X could create a job whose name matched "(cctbx|dials|xia2).*" User X could not create a job whose name did not match "(cctbx|dials|xia2).*" What actually happend: User X could see and click on "New Item" User X could successfully create a new job whose name matched "(cctbx|dials|xia2).*" User X attempted to created a new project with the name "dummy job" User X got HTTP ERROR 404 Problem accessing /job/dummy%20job/configure. Reason: Not Found It looks like the user was prevented creating a job with a name they are not authorised to access. However , Jenkins actually went ahead and created the job (it's visible in the "All" tab), so it looks like the authorisation test is being done too late. A friendlier error message would be nice, as well. Hope that helps.
            Hide
            danielbeck Daniel Beck added a comment -

            Actually, the job should be created, but the user has no permission to access it, as it does not match the name pattern. This seems to be a limitation inherent in how Role Strategy works.

            A friendlier error message would be nice, as well.

            May be possible if you give the user the Discover permission globally. Otherwise, Jenkins will simply deny there is such a job, as the user is not allowed to see it, and not allowed to learn of its existence.

            Show
            danielbeck Daniel Beck added a comment - Actually, the job should be created, but the user has no permission to access it, as it does not match the name pattern. This seems to be a limitation inherent in how Role Strategy works. A friendlier error message would be nice, as well. May be possible if you give the user the Discover permission globally. Otherwise, Jenkins will simply deny there is such a job, as the user is not allowed to see it, and not allowed to learn of its existence.
            Hide
            mwebber Matthew Webber added a comment -

            Actually, the job should be created, but the user has no permission to access it, as it does not match the name pattern. This seems to be a limitation inherent in how Role Strategy works.

            You are probably correct. I guess the problem here is in the Role Strategy UI - on my Jenkins, there are 19 different privileges that can be selected for a "role". "Role"s have a jobname pattern associated with them, and 1 of those 19 privileges, "Job/Create", it does not behave like the others, without any visual clue.

            > A friendlier error message would be nice, as well.

            May be possible if you give the user the Discover permission globally. Otherwise, Jenkins will simply deny there is such a job, as the user is not allowed to see it, and not allowed to learn of its existence.

            I tested this. With global Discover permission added, the user then gets a more sensible message:

            Access Denied
            Please login to access job dummy-job
            

            The message is not completely sensible, of course: the users is already logged in!

            The user then reported that the tabbed views at the top of the Jenkins page had disappaeared! This was shown to me. REMOVING the global "Discover" permission restored the view tabs. I cannot imagine what would cause that, I'm half doubting the evidence of my eyes, but it seemed to be as reported.

            Show
            mwebber Matthew Webber added a comment - Actually, the job should be created, but the user has no permission to access it, as it does not match the name pattern. This seems to be a limitation inherent in how Role Strategy works. You are probably correct. I guess the problem here is in the Role Strategy UI - on my Jenkins, there are 19 different privileges that can be selected for a "role". "Role"s have a jobname pattern associated with them, and 1 of those 19 privileges, "Job/Create", it does not behave like the others, without any visual clue. > A friendlier error message would be nice, as well. May be possible if you give the user the Discover permission globally. Otherwise, Jenkins will simply deny there is such a job, as the user is not allowed to see it, and not allowed to learn of its existence. I tested this. With global Discover permission added, the user then gets a more sensible message: Access Denied Please login to access job dummy-job The message is not completely sensible, of course: the users is already logged in! The user then reported that the tabbed views at the top of the Jenkins page had disappaeared! This was shown to me. REMOVING the global "Discover" permission restored the view tabs. I cannot imagine what would cause that, I'm half doubting the evidence of my eyes, but it seemed to be as reported.
            Hide
            podskalsky podskalsky added a comment -

            I have the same problem: the project role "Job create" with using the Restrict project naming "Role-Based Strategy" (defined pattern) is not running as mentioned.
            only the global role "Job create" is allowed to create Jobs, but without defined patterns

            Here is the Help text ...

            Help for feature: Role-Based Strategy

            Restricts Job creation according to role based settings. Global role allows create with any name, project role according to defined pattern

            Show
            podskalsky podskalsky added a comment - I have the same problem: the project role "Job create" with using the Restrict project naming "Role-Based Strategy" (defined pattern) is not running as mentioned. only the global role "Job create" is allowed to create Jobs, but without defined patterns Here is the Help text ... Help for feature: Role-Based Strategy Restricts Job creation according to role based settings. Global role allows create with any name, project role according to defined pattern
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            Seems Kanstantsin Shautsou is too busy to handle this issue.
            I'll try to reproduce it according to the comments above.

            • There's an issue in the code with Folders plugin. regexp filters for such jobs won't be applied correctly

            > The message is not completely sensible, of course: the users is already logged in!

            • There can be an impersonation issue within the code

            > The user then reported that the tabbed views at the top of the Jenkins page had disappaeared! This was shown to me. REMOVING the global "Discover" permission restored the view tabs. I cannot imagine what would cause that, I'm half doubting the evidence of my eyes, but it seemed to be as reported.

            No idea. I suppose it is not related to this issue. Please file a new one to role-strategy (or Jenkins core)

            Show
            oleg_nenashev Oleg Nenashev added a comment - Seems Kanstantsin Shautsou is too busy to handle this issue. I'll try to reproduce it according to the comments above. There's an issue in the code with Folders plugin. regexp filters for such jobs won't be applied correctly > The message is not completely sensible, of course: the users is already logged in! There can be an impersonation issue within the code > The user then reported that the tabbed views at the top of the Jenkins page had disappaeared! This was shown to me. REMOVING the global "Discover" permission restored the view tabs. I cannot imagine what would cause that, I'm half doubting the evidence of my eyes, but it seemed to be as reported. No idea. I suppose it is not related to this issue. Please file a new one to role-strategy (or Jenkins core)
            Hide
            simondevineau Simon Devineau added a comment -

            Hello everyone,

            First I would like to say thank you to Oleg and his team. This plugin is so powerfull.

            About this/these bug(s), I am sorry if I did not understand everything but here is my aim.

            I want a user (let's call him jobCreator) to be able to create jobs only if it respects a pattern otherwiswe it does not create it.
            If the user has the global create job he can do whatever he wants (Let's call him globalCreator)

            As it was said above, you need the global create job to be able to see the icon 'Create new item'.
            So the jobCreator will always have both permisisons (global and job)
            The globalCreator needs to have ONLY the global create permissions.

            I have modified the code of RoleBasedProjectNamingStrategy to follow my scenario.
            I cannot promise anything with it but if you want to check it out and update your code with, I will be glad.

            Also, I am not sure the current code is working.

            //firstly check global role
            SortedMap<Role, Set<String>> gRole = rbas.getGrantedRoles(RoleBasedAuthorizationStrategy.GLOBAL);
            for (SortedMap.Entry<Role, Set<String>> entry: gRole.entrySet())

            { if (entry.getKey().hasPermission(Item.CREATE)) return; }

            This will always return true because gRole contains all the users with all the global permissions.
            It should check the current logged user.

            I am gonna patch my code to your github if you are interested and attached it to my message.

            Could you please let me know about your intention.

            Show
            simondevineau Simon Devineau added a comment - Hello everyone, First I would like to say thank you to Oleg and his team. This plugin is so powerfull. About this/these bug(s), I am sorry if I did not understand everything but here is my aim. I want a user (let's call him jobCreator) to be able to create jobs only if it respects a pattern otherwiswe it does not create it. If the user has the global create job he can do whatever he wants (Let's call him globalCreator) As it was said above, you need the global create job to be able to see the icon 'Create new item'. So the jobCreator will always have both permisisons (global and job) The globalCreator needs to have ONLY the global create permissions. I have modified the code of RoleBasedProjectNamingStrategy to follow my scenario. I cannot promise anything with it but if you want to check it out and update your code with, I will be glad. Also, I am not sure the current code is working. //firstly check global role SortedMap<Role, Set<String>> gRole = rbas.getGrantedRoles(RoleBasedAuthorizationStrategy.GLOBAL); for (SortedMap.Entry<Role, Set<String>> entry: gRole.entrySet()) { if (entry.getKey().hasPermission(Item.CREATE)) return; } This will always return true because gRole contains all the users with all the global permissions. It should check the current logged user. I am gonna patch my code to your github if you are interested and attached it to my message. Could you please let me know about your intention.
            Hide
            simondevineau Simon Devineau added a comment -

            Here is the code I modified to follow my scenario

            Show
            simondevineau Simon Devineau added a comment - Here is the code I modified to follow my scenario
            Hide
            integer Kanstantsin Shautsou added a comment -

            I will try reproduce, but not today.

            Show
            integer Kanstantsin Shautsou added a comment - I will try reproduce, but not today.
            Hide
            simondevineau Simon Devineau added a comment -

            Ok thanks for your consideration.
            I will commit a new version on monday. I had some bugs in my code.

            Show
            simondevineau Simon Devineau added a comment - Ok thanks for your consideration. I will commit a new version on monday. I had some bugs in my code.
            Hide
            patrickw Patrick Wilkerson added a comment -

            Any update on this? We have the same issue and this feature would be great to have working.

            Show
            patrickw Patrick Wilkerson added a comment - Any update on this? We have the same issue and this feature would be great to have working.
            Hide
            fmignotet Florian Mignotet added a comment -

            Hi,

            We need the same feature too. Is there a fix in progress ?

            Thank you

            Show
            fmignotet Florian Mignotet added a comment - Hi, We need the same feature too. Is there a fix in progress ? Thank you
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            It's in my backlog, but I have to confirm that I have not found time to seriously revisit this task yet - too many other activities. No ETA right now. BTW I can perform all required reviews if somebody decides to work on this feature/issue

            Show
            oleg_nenashev Oleg Nenashev added a comment - It's in my backlog, but I have to confirm that I have not found time to seriously revisit this task yet - too many other activities. No ETA right now. BTW I can perform all required reviews if somebody decides to work on this feature/issue
            Hide
            hnain Harpreet Nain added a comment -

            I do see the Create permission in the project roles. Even though the project role has the create permission checked, the user assigned the project role is still not able to create jobs. The only way a use can create jobs is if it is included in the global role. Hence we are unable to restrict the project names due to this limitation. Please advise.

            Show
            hnain Harpreet Nain added a comment - I do see the Create permission in the project roles. Even though the project role has the create permission checked, the user assigned the project role is still not able to create jobs. The only way a use can create jobs is if it is included in the global role. Hence we are unable to restrict the project names due to this limitation. Please advise.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            The permission does not work in such way as you may expect. You still have to enable the global permission and then to enable the Role Strategy project name verifyer in order to get the functionality working. Without the Global permission the plugin thinks that the user cannot create any job (which is a valid behavior)

            Show
            oleg_nenashev Oleg Nenashev added a comment - The permission does not work in such way as you may expect. You still have to enable the global permission and then to enable the Role Strategy project name verifyer in order to get the functionality working. Without the Global permission the plugin thinks that the user cannot create any job (which is a valid behavior)
            Hide
            hnain Harpreet Nain added a comment -

            ok thanks! Got it. The help text on the project name verifier config was a bit misleading. Noticed that even though it disables the user to configure or run that job that does to follow the pattern, the job still gets created. Would have been neat if it would give an error and not generate unnecessary jobs.

            Show
            hnain Harpreet Nain added a comment - ok thanks! Got it. The help text on the project name verifier config was a bit misleading. Noticed that even though it disables the user to configure or run that job that does to follow the pattern, the job still gets created. Would have been neat if it would give an error and not generate unnecessary jobs.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -
            Show
            oleg_nenashev Oleg Nenashev added a comment - Harpreet Nain agreed
            Hide
            danielbeck Daniel Beck added a comment -

            ItemListener has checkBeforeCopy but of course no checkBeforeCreate, I hate these narrow API additions that make things a mess.

            Show
            danielbeck Daniel Beck added a comment - ItemListener has checkBeforeCopy but of course no checkBeforeCreate , I hate these narrow API additions that make things a mess.
            Hide
            oleg_nenashev Oleg Nenashev added a comment -

            I added it to the GSoC 2019 project idea as an UX improvement (better validation of what is being created). As Daniel Beck says, new APIs may be needed to make it possible. Also, "Allow creating a job to which the user has no permission in Role Strategy" is actually a valid use-case for some configurations of Ownership-based security when ownership is being automatically set upon creation. https://github.com/jenkinsci/ownership-plugin/blob/master/doc/OwnershipBasedSecurity.md

            Show
            oleg_nenashev Oleg Nenashev added a comment - I added it to the GSoC 2019 project idea as an UX improvement (better validation of what is being created). As Daniel Beck says, new APIs may be needed to make it possible. Also, "Allow creating a job to which the user has no permission in Role Strategy" is actually a valid use-case for some configurations of Ownership-based security when ownership is being automatically set upon creation. https://github.com/jenkinsci/ownership-plugin/blob/master/doc/OwnershipBasedSecurity.md
            Hide
            yaswanth07 yaswanth badam added a comment -

            Hi Team,

            We are also facing the same. 

            We have created testRole in Global Roles which have overall READ permission.

            We have created testProjectRole in projectRoles which have below permissions.

            JOB: BUILD,CANCEL,CREATE,CONFIGURE,READ with pattern "test.*"

             

            Observations:

             1) Initially we did not give JOB create option in GLOBAL roles so testUser not able to see the "NEW ITEM"

            2) Later we have given JOB create option in GLOBAL roles so testUser able to see the "NEW ITEM" and he will create the job using the pattern "testDev" successfully.

            3) So here is the issue the user can able to create job apart from pattern which is displaying 404 error, but in backend the job is creating when we logged with admin user. So i want the JOB will not create apart from Pattern in project Roles.

             

            Could you please advice on this request.

             

            Thanks

            Yaswanth

            Show
            yaswanth07 yaswanth badam added a comment - Hi Team, We are also facing the same.  We have created testRole in Global Roles which have overall READ permission. We have created testProjectRole in projectRoles which have below permissions. JOB: BUILD,CANCEL,CREATE,CONFIGURE,READ with pattern "test.*"   Observations:  1) Initially we did not give JOB create option in GLOBAL roles so testUser not able to see the "NEW ITEM" 2) Later we have given JOB create option in GLOBAL roles so testUser able to see the "NEW ITEM" and he will create the job using the pattern "testDev" successfully. 3) So here is the issue the user can able to create job apart from pattern which is displaying 404 error, but in backend the job is creating when we logged with admin user. So i want the JOB will not create apart from Pattern in project Roles.   Could you please advice on this request.   Thanks Yaswanth

              People

              • Assignee:
                oleg_nenashev Oleg Nenashev
                Reporter:
                mwebber Matthew Webber
              • Votes:
                15 Vote for this issue
                Watchers:
                20 Start watching this issue

                Dates

                • Created:
                  Updated: