[JENKINS-19934] fix project naming strategy #179
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
11 tasks
mawinter69
changed the title
The project naming strategy is currently not considering if the user has the permission to create a job with a given name at all. I just checks if the passed name matches any of the patterns. Also it doesn't consider the full name, e.g. when a project is created inside a folder. This can lead to the situtation that a user creates a job but is then unable to configure the job. This change will do the following: Prerequisites: - Rolebased project naming strategy is enabled. - for each role when create is enabled also configure and read should be enabled If a user has either globally or in any item role the create permission then he will see the "New item" link in the side panel. A user that has global create permissions can create jobs with any name. For a user that has create permission on one or more item roles the entered name is matched against the role and the users permissions. Current limitation is that it only works reliably via the UI. When trying to create a job via the CLI, there is no staplerrequest that can be used to find the parent item. So job creation via cli will fall back to the old behaviour and just check the item name itself. In case JENKINS-68602 gets resolved requests coming in via the CLI would also be properly checked. This also adds an admin monitor that warns when the role based project naming strategy is not enabled.
can't use the code path from authorities as roles that is wrong. Add tests that verify group permissions work properly
mawinter69
force-pushed
the
fix-namingstrategy
branch
from
870e59b to
f61f7b8
Compare
mawinter69
force-pushed
the
fix-namingstrategy
branch
from
a8d1180 to
6f1f1e8
Compare
mawinter69
force-pushed
the
fix-namingstrategy
branch
from
6f1f1e8 to
acc0357
Compare
6 tasks
This was referenced Jul 28, 2022
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
The project naming strategy is currently not considering if the user
has the permission to create a job with a given name at all. It just
checks if the passed name matches any of the patterns.
Also it doesn't consider the full name, e.g. when a project is created
inside a folder.
This can lead to the situation that a user creates a job but is then
unable to configure the job.
This change will do the following:
Prerequisites:
be enabled
If a user has either globally or in any item role the create permission
then he will see the "New item" link in the side panel.
A user that has global create permissions can create jobs with any name.
For a user that has create permission on one or more item roles the
entered name is matched against the role and the users permissions.
Current limitation is that it only works reliably via the UI. When
trying to create a job via the CLI, there is no staplerrequest that can
be used to find the parent item. So job creation via cli will fall back
to the old behaviour and just check the item name itself.
In case JENKINS-68602 (see core PR 6598) gets resolved requests coming in via the CLI would
also be properly checked.
This also adds an admin monitor that warns when the role based project
naming strategy is not enabled.
Other PR (#9, #16) also tried to solve the problem but mainly lack the fact that without global create permissions you do not get the corresponding link.
Considering performance I think that the looping over the authorities is not a big problem as the method is not called so frequently. Not sure if there will be a noticeable delay when typing a new job name and many item roles are configured.