The same issue.

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.

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".

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)

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.

"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

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

>> 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.

What Jenkins Core version do you use?

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

integer, any updates?

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

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

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

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.

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.

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.

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.

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

Seems integer 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)

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.

Here is the code I modified to follow my scenario

I will try reproduce, but not today.

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

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

Hi,

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

Thank you

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

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)

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.

hnain agreed

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

I added it to the GSoC 2019 project idea as an UX improvement (better validation of what is being created). As danielbeck 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

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

With this release and using the role based naming strategy, job create permissions are properly respected.

If anyone is still experiencing this issue, It is resolved by following these steps:

In manage and assign roles: Give the corresponding item role: Job/create, Job/read, and Job/configure permissions.
In configure system: enable the checkbox for "restrict project naming" with the dropdown checkbox "Role-Based Strategy".

Users who are a member of the item role now have the "new item" box available on the side panel and permissions to only create jobs following the specified pattern