Project

General

Profile

Actions

Feature #1086

open

Fine grained permissions

Added by Cory Nelson over 16 years ago. Updated over 2 years ago.

Status:
New
Priority:
Normal
Assignee:
-
Category:
Permissions and roles
Target version:
-
Start date:
2008-04-22
Due date:
% Done:

0%

Estimated time:
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 otherNew2008-09-04

Actions
Related to Redmine - Feature #2636: Feature Request: Wiki ACLs (Access control for individual pages)New2009-01-31

Actions
Related to Redmine - Feature #4550: Allow access to files & documents to be configurable for each entry by user roleNew2010-01-11

Actions
Related to Redmine - Feature #2076: Individual Permissions for Each ProjectClosed2008-10-23

Actions
Has duplicate Redmine - Feature #1428: More granular module permissions in projectsClosed2008-06-12

Actions
Actions #1

Updated by James Byrne over 16 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.

Actions #2

Updated by Jean-Philippe Lang over 16 years ago

  • Target version deleted (0.8)
Actions #3

Updated by colin moock over 16 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.

Actions #4

Updated by colin moock over 16 years ago

Issue #850 looks like a dupe of this issue.

Actions #5

Updated by Vladymyr Vladymyrov over 16 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.

Actions #6

Updated by Kaota Tashuko about 16 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.

Actions #7

Updated by Burt Culver about 16 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.

Actions #8

Updated by Juris P almost 16 years ago

+1

Actions #9

Updated by Fredrik Frodlund almost 16 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).

Actions #10

Updated by Jean-Philippe Lang almost 16 years ago

  • Category set to Permissions and roles
Actions #11

Updated by Werner KLINGER over 15 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.

Actions #12

Updated by Ве Fio over 14 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!!

Actions #13

Updated by Benjamin Neau over 14 years ago

+1.

Actions #14

Updated by Mario Bouhaidar over 14 years ago

+ 1

Actions #15

Updated by Marcelo Fernandes almost 14 years ago

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

Actions #16

Updated by Anonymous over 13 years ago

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

Actions #17

Updated by Esteban Bordon over 13 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

Actions #18

Updated by Ian Chan over 13 years ago

+1

Actions #19

Updated by Giovani Spagnolo about 13 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...

Actions #20

Updated by Axel Clifford almost 13 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.

Actions #21

Updated by Vasa Maximov over 12 years ago

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

Actions #22

Updated by Charles Spivey over 12 years ago

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

Actions #23

Updated by carlos lopez about 12 years ago

+1

Actions #24

Updated by Yehuda Katz about 12 years ago

+1

Actions #25

Updated by Hrobky Hrobky about 12 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.

Actions #26

Updated by Boaz Rymland about 12 years ago

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

Actions #27

Updated by Terence Mill about 12 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 !

Actions #28

Updated by Florian Kaiser over 10 years ago

+1

Actions #29

Updated by Toshi MARUYAMA over 10 years ago

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

Updated by Toshi MARUYAMA about 10 years ago

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

Updated by Toshi MARUYAMA about 10 years ago

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

Updated by Mahyar Ahmadpour-B. over 8 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
Actions #33

Updated by Zer Guz about 8 years ago

+1

Actions #34

Updated by Yurii Panasenco over 2 years ago

+1

Actions

Also available in: Atom PDF