Feature #18640
open
Projects accessible by members and authenticated users only
0%
Description
#17976 introduced groups for non-member and anonymous users, those users seem to still only be able to see and interact with public projects (tested on 2.6-stable).
This is confusing as it is possible to add the non-member and anonymous groups to private projects. It should either be possible to only add these groups if the project is public, or (even better) remove the "public project" mechanism and replace it completely with the new groups.
Related issues
Updated by Jean-Philippe Lang over 9 years ago
Yes, anonymous and non member users cannot access private project even if they were given some permissions (just like a 777 file in a 600 directory isn't readable to other users). There's one specific use case where it can be usefull: a private parent project with public subprojects that inherit memberships. So I'm not sure we should remove this possibility.
Updated by Felix Schäfer over 9 years ago
We (Planio) had a customer with a specific use-case, that I don't think is currently possible: They need to have some projects visible for everyone, even non-members and anonymous, and some projects visible for non-members but not for anonymous.
Removing the "public" flag on projects and replacing it completely with the non-member and anonymous groups, it would be possible to achieve a setup like this. That would also avoid that there are 2 distinct and "competing" settings for anonymous and non-member access.
If there is a direction with which you think our customer's problem can be solved that you would consider merging into core, we will probably be able to contribute some work towards that.
Updated by Jean-Philippe Lang over 9 years ago
- Tracker changed from Defect to Feature
- Subject changed from Anonymous/non-members have no access to private projects they are member of to Projects accessible by members and authenticated users only
Felix Schäfer wrote:
We (Planio) had a customer with a specific use-case, that I don't think is currently possible: They need to have some projects visible for everyone, even non-members and anonymous, and some projects visible for non-members but not for anonymous.
Indeed, it's not possible to set projects accessible by authenticated users but not anonymous users.
Removing the "public" flag on projects and replacing it completely with the non-member and anonymous groups, it would be possible to achieve a setup like this. That would also avoid that there are 2 distinct and "competing" settings for anonymous and non-member access.
If there is a direction with which you think our customer's problem can be solved that you would consider merging into core, we will probably be able to contribute some work towards that.
Removing the "public" flag would be an option but not the most intuitive IMHO: having to add 2 groups as members and chosing some roles for them (the default roles in many cases) instead of just checking a "Public" flag doesn't sound like an improvement.
The above use case (project accessible by members and authenticated users only) would require to replace the visibility flag with a 3 option choice (private, authenticated users, public).
Updated by Felix Schäfer over 9 years ago
Jean-Philippe Lang wrote:
Removing the "public" flag would be an option but not the most intuitive IMHO: having to add 2 groups as members and chosing some roles for them (the default roles in many cases) instead of just checking a "Public" flag doesn't sound like an improvement.
The above use case (project accessible by members and authenticated users only) would require to replace the visibility flag with a 3 option choice (private, authenticated users, public).
I find it confusing to have 2 different settings for access ("public/private" setting in one tab and "members" in another tab), but that might only apply because I'm a "power user" :-)
How about extending the setting from "public/private" to "public/authenticated only/private", move it to the "members" tab in the project settings and have the setting add the default group with the default role automatically, as is the case for user added automatically by a group?
Updated by Mattias Vannergård almost 9 years ago
I think it would be a good idea. If you move it to the "members" tab, we can also select which group(s) that are authenticated to view the project.
In that way we can rely on group membership for visibility.
Updated by Mischa The Evil over 6 years ago
- Related to Feature #27731: Allow users to view and comment on their own issues, even if moved into a project where they don't have access. added