Feature #4164

Block access to public projects

Added by Nicolas Gauthier almost 13 years ago. Updated almost 12 years ago.

Status:ClosedStart date:2009-11-04
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:-
Target version:-
Resolution:Wont fix

Description

It would be nice to be able to say that a user cannot see the projects that are public.

In my company we want to have public projects so every employee can consult them and create bug issues.

However, we also want to create users for our clients and we don't want that those "extern users" can see our "internal public projects"

Add a checkbox for that in the user edit form could be nice (see picture)

picture1.PNG (12.2 KB) Nicolas Gauthier, 2009-11-04 19:35

History

#1 Updated by Felix Schäfer almost 13 years ago

-1, I think this shouldn't be too hard to realize with the existing authorization architecture, e.g. just create a group "employees" and add it to your internal projects.

#2 Updated by Nicolas Gauthier almost 13 years ago

It's effectively a possible way, but is there a way that the redmine groups could be bound to the LDAP groups? Or can we set a "default" group for the "on-the-fly" connection from the LDAP?

Because it's awkward to have to put manually every new user in the "employee" group...

We are currently using 0.8.5 and I haven't seen those possibilities during my test with the trunk.

#3 Updated by Nicolas Gauthier almost 13 years ago

I meant "on-the-fly" user creation from the LDAP

#4 Updated by Jean-Philippe Lang almost 13 years ago

  • Status changed from New to Closed
  • Resolution set to Wont fix

It's effectively a possible way, but is there a way that the redmine groups could be bound to the LDAP groups? Or can we set a "default" group for the "on-the-fly" connection from the LDAP?

There's already a feature request about LDAP groups. And that makes sense, unlike blocking access to public projects.
Authorization model is complex enough, public projects will stay public.

#5 Updated by Nicolas Gauthier almost 13 years ago

There's already a feature request about LDAP groups. And that makes sense, unlike blocking access to public projects.
Authorization model is complex enough, public projects will stay public.

Indeed that makes sense. +1 for LDAP groups then

Thanks for the quick responses

#6 Updated by Bruno Medeiros almost 12 years ago

I have the same problem, but I agree that make public projects non-public would be a kind of hack.

I need to solve this problem, and I agree that support internal LDAP groups (#4755) would be hard to implment and would require a lot of tests, so I created a more simple feature request that only asks to allow a default group to each ldap source (#6202). If someone like it, just vote :)

Also available in: Atom PDF