You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We have different teams that are working on different project types (mainly language based).
Our namespaces are named after these project types e.g. java-projects, python-projects or r-projects.
These namespaces are then automatically read and build via jenkins with the help of the scm plugin on jenkins side.
At the moment all repositories for each team must be created from someone that has the global "Create Repository" right.
I would like to define a namespace owner that can create repositories in a specific namespace to lighten the administrative overhead when a team creates a new project because creating the repository is the only part in out infrastructure (atm.) where a global admin has to step in.
Proposed solution
Best would be if there was a right "Create Repository" on the namespace level (like it exists for reading and writing).
This proberly also needs a bit of validation on the "Create Repository" form so that a user can only create a repository in the namespaces where he is allowed.
This would also integrate partly with #1723 so that the list is prefiltered to the allowed namespaces (maybe also with a change from a autocomplete field to a combobox).
The text was updated successfully, but these errors were encountered:
This sounds good. What comes into my mind is a namespace strategy, where you can assign namespaces to users and groups. These are then selectable as namespaces. As a bonus, one could link these namespaces with permissions, so that they cannot diverge.
Would that mean the namespace definition would be moved to a global reference list (new namespaces are definied like roles in a new tab) and no longer be created on the fly?
That sounds good and could work. As long as i can freely name these namespaces (not like with the other namespace strategies where the name is static).
Namespace Strategies can be anything. The only boundary from my side is a appropriate level of generality, so that a plugin is not only useful for a single user.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
stalebot
added
the
stale
Issue is stale and will be closed if no further activity occurs
label
Jan 18, 2022
Issue description
Feature Request
Problem to be solved
We have different teams that are working on different project types (mainly language based).
Our namespaces are named after these project types e.g. java-projects, python-projects or r-projects.
These namespaces are then automatically read and build via jenkins with the help of the scm plugin on jenkins side.
At the moment all repositories for each team must be created from someone that has the global "Create Repository" right.
I would like to define a namespace owner that can create repositories in a specific namespace to lighten the administrative overhead when a team creates a new project because creating the repository is the only part in out infrastructure (atm.) where a global admin has to step in.
Proposed solution
Best would be if there was a right "Create Repository" on the namespace level (like it exists for reading and writing).
This proberly also needs a bit of validation on the "Create Repository" form so that a user can only create a repository in the namespaces where he is allowed.
This would also integrate partly with #1723 so that the list is prefiltered to the allowed namespaces (maybe also with a change from a autocomplete field to a combobox).
The text was updated successfully, but these errors were encountered: