Feature #1086

Fine grained permissions

Added by Cory Nelson over 11 years ago. Updated almost 3 years ago.

Status:NewStart date:2008-04-22
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Permissions and roles
Target version:-
Resolution:

Description

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.


Related issues

Related to Redmine - Feature #1853: Make Projects truly independent of each other New 2008-09-04
Related to Redmine - Feature #2636: Feature Request: Wiki ACLs (Access control for individual... New 2009-01-31
Related to Redmine - Feature #4550: Allow access to files & documents to be configurable for ... New 2010-01-11
Related to Redmine - Feature #2076: Individual Permissions for Each Project Closed 2008-10-23
Duplicated by Redmine - Feature #1428: More granular module permissions in projects Closed 2008-06-12

History

#1 Updated by James Byrne over 11 years ago

  • Target version set to 0.8

++1

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.

#2 Updated by Jean-Philippe Lang over 11 years ago

  • Target version deleted (0.8)

#3 Updated by colin moock over 11 years ago

+1
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.

#4 Updated by colin moock over 11 years ago

Issue #850 looks like a dupe of this issue.

#5 Updated by Vladymyr Vladymyrov over 11 years ago

It would be also very useful to have permissions selection for every module: forum/wiki/time tracker/estimate field.

For our project we are in real need of hiding time estimates and time tracking log from customer.

#6 Updated by Kaota Tashuko almost 11 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 almost 11 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.

#8 Updated by Juris P almost 11 years ago

+1

#9 Updated by Fredrik Frodlund almost 11 years ago

+1

I'd like to have even more granular permissions for public users, which would effectively dissallow them to assign issues to specific persons. Actually what I want is to hide certain parts of the form (not just the "Assigned to" field).

#10 Updated by Jean-Philippe Lang over 10 years ago

  • Category set to Permissions and roles

#11 Updated by Werner KLINGER over 10 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 9 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!!

#13 Updated by Benjamin Neau over 9 years ago

+1.

#14 Updated by Mario Bouhaidar about 9 years ago

+ 1

#15 Updated by Marcelo Fernandes almost 9 years ago

+1 I do need setup 'documents' section per project.

#16 Updated by Anonymous over 8 years ago

+1 And having possibility of modifying Anonymous and Non Members roles per project would be even better.

#17 Updated by Esteban Bordon over 8 years ago

Viliam Pucik wrote:

+1 And having possibility of modifying Anonymous and Non Members roles per project would be even better.

+1
Where I work it would be really good

#18 Updated by Ian Chan over 8 years ago

+1

#19 Updated by Giovani Spagnolo about 8 years ago

+1
it would be useful to protect some "documents" folders for example to show procurement documents folder only to managers but not to developers; show technical level folders to developers and not to external stakeholders, and so on...

#20 Updated by Axel Clifford almost 8 years ago

+1

We have a need to add external contractors to a specific project, but I do not want to allow them to see any of our other projects, tickets, wikis, etc.

#21 Updated by Vasa Maximov over 7 years ago

+1
I need to restrict access to some wiki pages only for the team leaders

#22 Updated by Charles Spivey about 7 years ago

+1
It would be really nice to have the ability to set view/edit permissions to wiki pages.

#23 Updated by carlos lopez about 7 years ago

+1

#24 Updated by Yehuda Katz almost 7 years ago

+1

#25 Updated by Hrobky Hrobky almost 7 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.

#26 Updated by Boaz Rymland almost 7 years ago

+1. Would be nice to have sections of the wiki blocked to certain users.

#27 Updated by Terence Mill almost 7 years ago

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.

+1 also !

#28 Updated by Florian Kaiser over 5 years ago

+1

#29 Updated by Toshi MARUYAMA about 5 years ago

  • Related to Feature #2636: Feature Request: Wiki ACLs (Access control for individual pages) added

#30 Updated by Toshi MARUYAMA about 5 years ago

  • Related to Feature #4550: Allow access to files & documents to be configurable for each entry by user role added

#31 Updated by Toshi MARUYAMA about 5 years ago

  • Related to Feature #2076: Individual Permissions for Each Project added

#32 Updated by Mahyar Ahmadpour-B. about 3 years ago

+1. Also this permission should be per tracker, parent/child relation or related issues. I suggest such permissions for issues' visibility with multiselectablity feature:
  1. Assigned Issues
  2. Owned Issues
  3. Issues related to owned/assigned
  4. Parents of owned/assigned issues
  5. Children of owned/assigned issues

#33 Updated by Zer Guz almost 3 years ago

+1

Also available in: Atom PDF