Project

General

Profile

Actions

Feature #4164

closed

Block access to public projects

Added by Nicolas Gauthier over 14 years ago. Updated over 13 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
2009-11-04
Due date:
% Done:

0%

Estimated time:
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)


Files

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

Updated by Felix Schäfer over 14 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.

Actions #2

Updated by Nicolas Gauthier over 14 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.

Actions #3

Updated by Nicolas Gauthier over 14 years ago

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

Actions #4

Updated by Jean-Philippe Lang over 14 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.

Actions #5

Updated by Nicolas Gauthier over 14 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

Actions #6

Updated by Bruno Medeiros over 13 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 :)

Actions

Also available in: Atom PDF