Type: New Feature
Affects Version/s: 3.3.1
Fix Version/s: None
In Our Company we host one Central Artifactory for all Projects. As we are a full service IT Company and no it-product company all projects are way different with different people...
Each Project we have in our company get’s it’s own set of LOCAL repositories (usually a release repo, one snapshot repo and one 3rd-partylibs-repo for libs that are not on remot erepos.)
These Repos get own permission targets where only special directory-groups get permission to.
Each Project gets one or two virtual repositories containing the local repositories and the set of remote/cache repositories they need for successful builds
Sadly the current Permission Management does not fit to this scenario because ( "+" means: good behaviour; "-" means: bad behaviour):
+ Users can only download from repositories they have permission to
+ Users can only deploy to repositories they have permission to
+ users only see local repositories they have permission to
+ users can only see remote/cache repos they have permission to
- Users see ALL Virtual Repositories by name although they have no permission to certain local repositories that are boudn to the virtual one
- user see ALL Builds in the Builds-Browser if they have at least one "deployer"-permission on one local/remote repository (that's worst)
- adminsitrator must pay good attention by setting up permission target
- adding a LDAP-Group into Artifactory is harmful (import-button etc...)
I'd like to see a permission management system that covers our usage scenario:
permisions for: Build Browser-View-parts (e.G. also "only license tab for certain users", permissions for virtual repos (see or not to see), NO IMPORTING of LDAP-Groups (just search them), ...
If you like I can go more in detail but at first I like to hear your opinion if this is a case that may be implemented in future versions or what plans you have.
for us it's more ore less important: As if we want to open a certain instance for customer-access detailed permissions is needed.