Fine grained permissions
|Category:||Permissions and roles|
Permissions should be appliable per-forum, per-wiki page, per-download, etc. - A team might have some internal documents and other external documents. A support forum, and a developer forum.
#1 Updated by James Byrne over 12 years ago
- Target version set to 0.8
The existing permissions structure set at the instance level could become the default, but allowing project managers to override and set user role permissions on a per-project basis would be very useful. Further allowing project managers to set access limits on forums and wiki pages to a collection of roles would greatly enhance the usability of Redmine for providing client facing portions respecting support issues.
#3 Updated by colin moock over 12 years ago
i'm very interested in per-project permissions too. we're about to launch a software company with public issue-tracking in redmine. for some projects, we want to let anonymous users view the code repository. for others, we want to restrict anonymous users from viewing the code repository.
we're relying on redmine as our entire "dev community" site, and this is the first feature we've found that's a blocker on our plans.
#6 Updated by Kaota Tashuko about 12 years ago
I would like to express my agreement for having this issue resolved.
I started a project using Redmine but was dismayed at the lack of permissions tuning. If Roles as previously noted could be applied to individual portions of a project (forums, wiki, etc) that would make my day. Ideally I want a forum that only the developers can see and use, and a forum for the public; same with a few wiki pages; and no, just starting separate projects isn't the answer.
#7 Updated by Burt Culver about 12 years ago
+1 Our organisation doesn't use the wiki features of Redmine exactly because we don't have user level control over who can view what pages. We'ld like to have the ability to say persons A, B, C can see/edit the page but no one else. Group level permissions would be a nice to have but not a requirement. We'd love to dump our phpwiki and start using redmine wiki. None of us code Ruby unfortunately so we can't help with the coding.
#11 Updated by Werner KLINGER over 11 years ago
I was looking for a specific, simple feature: allow either wiki, forum, to be made "public" whereas other modules are kept non public (like trackers, repository). My "feature request" would rather be #1428, but as it is closed and said to be duplicate of this one...
So, to sum up: I would first like to have the ability to make modules (forum, wiki, repository...) visible (read) and accessible (read/write) per user groups. For instance: I may make the wiki readable by all, only updated by project members users, forum available to any registered user, but access to all other modules (repository, trackers...) would still be restricted to project members ; Thus, I would suggest to re-open #1428 to track this "simple" feature.
Regarding this (#1086) request, I like the idea, meaning fine granularity down to wiki pages, forums (make not all forums at once public, only selected ones), but it sounds to me like being very complicated to implement.
#12 Updated by Ве Fio over 10 years ago
Please bring this in. I need to host both open source projects and closed source projects, and I want to be able to browse the repository of my closed source apps (ONLY me and my developers should have access to that part), and allow everyone access to the open source repositories. I cannot do this with the current system. The current system is an all-or-nothing model.
I know I would be able to do what I need to do if only permission defaults were able to be overridden on a per project basis! Please fix this!!
#25 Updated by Hrobky Hrobky about 8 years ago
This would be really comfortable, but I'm achieving this effect by sub-projects. Permission checking in Redmine is well done: you don't even see projects, you don't have access to; and you cannot click on inter-project wiki/document links, when not having access rights to the target.
What's really interesting thing is:
Viliam Pucik wrote:
+1 And having possibility of modifying Anonymous and Non Members roles per project would be even better.
#32 Updated by Mahyar Ahmadpour-B. over 4 years ago
- Assigned Issues
- Owned Issues
- Issues related to owned/assigned
- Parents of owned/assigned issues
- Children of owned/assigned issues