Project

General

Profile

Actions

Feature #7412

closed

Add an issue visibility level to each role

Added by Jean-Philippe Lang almost 14 years ago. Updated over 10 years ago.

Status:
Closed
Priority:
Normal
Assignee:
-
Category:
Issues permissions
Target version:
Start date:
2011-01-22
Due date:
% Done:

0%

Estimated time:
Resolution:
Fixed

Description

This new option will allow each role to see all or certain issues only.

  • all => all issues including others privates issues
  • default => all public issues and private issues created by or assigned to the user
  • own issues => only issues created by or assigned to the user

A user having multiple roles on a project gets the highest level from its roles.


Related issues

Related to Redmine - Feature #337: Private issuesClosedJean-Philippe Lang

Actions
Related to Redmine - Feature #1554: Private comments in ticketsClosedJean-Philippe Lang2008-06-30

Actions
Related to Redmine - Feature #8488: Create an 'Involve' mechanism to private issuesNew

Actions
Related to Redmine - Feature #4167: Issues access: to allow a user view ONLY issues that his is assigned onClosed2009-11-05

Actions
Has duplicate Redmine - Feature #2331: Restricting issue listing for some roles to display only owned and assigned ticketClosed2008-12-12

Actions
Has duplicate Redmine - Feature #2653: New permission for issues: view_own_issueClosed2009-02-03

Actions
Has duplicate Redmine - Feature #6331: Give a role a permission to view/edit only his ticketsClosed2010-09-08

Actions
Actions #1

Updated by Radek Antoniuk almost 14 years ago

I am really waiting for the "own issues" feature. This is not hard to implement I think and this is quite basic for me to have.
Thanks for a great tool!

Actions #2

Updated by Bruno Medeiros almost 14 years ago

Jean-Philippe,

Can you consider put the observed issues on the default level? It's done by the patch provided on #2653 and is very useful. It allows us to involve someone in a specific ticket putting them as observer (and without need to change the user's role).

Actions #3

Updated by Vladimir Dzalbo almost 14 years ago

I am thinking it could make sense to change it following:

  • all => all issues including others privates issues
  • default => all public issues and private issues created by or assigned to the user, or watched by user
  • own issues => only issues created by or assigned to the user, or watched by user

I'll explain: many organizations want to give external access to their customers or suppliers to the issue. Now, naturally they would prefer to have very limited access, probably Own issues only. But then the problem arises: if an issue was created by normal user and is assigned to normal user, externals won't have access to it. Making an external user a watcher would solve this problem (and on security level there is not much risk: users cannot add themselves to issues, which they cannot see)

Actions #4

Updated by Brian Lindahl almost 14 years ago

This feature should also be coupled with a similar editing privilege: 'edit own issues'. See my patch #7444 for an implementation (also contains other issue editing permissions).

Actions #5

Updated by Maciej Czub almost 14 years ago

This feature should be implemented also on lower level (notes). Company using Redmine could show some notes to clients as official messages, but hide other notes (visible only to employees).

Actions #6

Updated by Etienne Massip almost 14 years ago

Vladimir Dzalbo wrote:

I am thinking it could make sense to change it following:

  • all => all issues including others privates issues
  • default => all public issues and private issues created by or assigned to the user, or watched by user
  • own issues => only issues created by or assigned to the user, or watched by user

Couldn't that be :

* all => all issues including others privates issues
* default => all public issues and private issues watched by user
* own issues => only issues watched by user

And we add a mechanic so that author and assignee(s), when assigned, are automatically added to the watchers list ?

That would solve #6914

Actions #7

Updated by Etienne Massip almost 14 years ago

Sorry, forget about my last comment, tired.

Actions #8

Updated by Brian Lindahl almost 14 years ago

Etienne:

I don't like that much. What if you only have the 'view own issues' permission, and you decide you don't want notifications (removed from watchers list), but you DO want to still be able to see the issue and track it manually (i.e. in software engineering terminology: you want to poll the status of the issue, rather than receive an event notification of the issue status).

I do like the 'automatically added to the watchers list' idea, though. That's an elegant solution for #6914, and it would be really nice to automatically start receiving notifications once an issue is assigned to you.

Actions #9

Updated by Etienne Massip almost 14 years ago

Yes, that comment was about email notification, not about the current subject.

Actions #10

Updated by Bruno Medeiros over 13 years ago

Main contributors, can you give us some feedback about the proposal of including watchers on 'default' and 'own issues' levels? It's explained on 3rd comment by Vladimir Dzalbo.

Actions #11

Updated by Fernando Hartmann over 13 years ago

Bruno Medeiros wrote:

Main contributors, can you give us some feedback about the proposal of including watchers on 'default' and 'own issues' levels? It's explained on 3rd comment by Vladimir Dzalbo.

I agree with the proposal of Vladimi Dzalbio. In my opinion this (include the watchers in default and owned ) is the best option. This can solve a lot of problems to me and my organization.

Actions #12

Updated by Maciej Czub over 13 years ago

Redmine is often used as helpdesk/ticket system. Setting visibility for single notes in issues is also very important.

Actions #13

Updated by Jean-Philippe Lang over 13 years ago

  • Status changed from New to Closed
  • Resolution set to Fixed

Feature was added in r5416.

Vladimir Dzalbo wrote:

I am thinking it could make sense to change it following:

  • all => all issues including others privates issues
  • default => all public issues and private issues created by or assigned to the user, or watched by user
  • own issues => only issues created by or assigned to the user, or watched by user

This change was not done. It could be handy in some cases but, as Brian Lindahl said, watchers were designed for notification purpose only. A user who unwatches a private issue would lost access to it. It may be quite confusing for many users.

That said, it wouldn't be hard to implement, just need to adapt Issue#visible_condition and Issue#visible?. I'm thinking about adding an API to change or define new access rules (eg. in a plugin).

Actions #14

Updated by Bruno Medeiros over 13 years ago

Jean-Philippe, do you think it's a good idea to create a "Involve" mechanism, that would be very similar to watch mechanism? So roles with 'involve_user' permission can add someone to the private issue, in a similar way people with 'add_watcher' permission add a watcher today.
If you like this I can create a new ticket and post a detailed description.

Actions #15

Updated by Ling Li over 13 years ago

Thanks for implementing this. I am confused on one scenario though:

If a user doesn't have the privilege to see a private issue, but is added as a watcher to this private issue (say, by the manager), what would that user see (if her visibility_level is default)? Is it true that she will receive email updates but can't click/see the issue via the web interface?

Actions #16

Updated by Jean-Philippe Lang over 13 years ago

Bruno Medeiros wrote:

Jean-Philippe, do you think it's a good idea to create a "Involve" mechanism, that would be very similar to watch mechanism? So roles with 'involve_user' permission can add someone to the private issue, in a similar way people with 'add_watcher' permission add a watcher today.

This may be a feature to consider for a future release.

Ling Li wrote:

Thanks for implementing this. I am confused on one scenario though:

If a user doesn't have the privilege to see a private issue, but is added as a watcher to this private issue (say, by the manager), what would that user see (if her visibility_level is default)? Is it true that she will receive email updates but can't click/see the issue via the web interface?

That user won't see the issue and won't receive notifications even if he is added as a watcher. Maybe we should warn or even prevent from adding a watcher that is not allowed to view the issue.

Actions #17

Updated by Radek Antoniuk over 13 years ago

Maybe we should warn or even prevent from adding a watcher that is not allowed to view the issue.

Definitely agree on that. Imho it should be prohibited.

Actions #18

Updated by Ryan Cross over 13 years ago

Anxious to test this out, but I"m curious about the "private" only being for tickets some has reported or assigned to..

As a use case>

If i create a ticket and assign to nobody -> great only I can see the ticket
If i assign it to someone -> great, I and that person can see it.
If that person updates it and assigns it back to me to follow up -> bad - that person can't access it because he is no longer assigned to the ticket.

If the above use case if resolved by making it accessible to "a user that has ever been assigned to that ticket historically", then I also wonder about how a person can be removed from a private ticket. Would you have to some how remove their involvement from the history of the ticket??

Actions #19

Updated by Ling Li over 13 years ago

Jean-Philippe Lang wrote:

Bruno Medeiros wrote:

Jean-Philippe, do you think it's a good idea to create a "Involve" mechanism, that would be very similar to watch mechanism? So roles with 'involve_user' permission can add someone to the private issue, in a similar way people with 'add_watcher' permission add a watcher today.

This may be a feature to consider for a future release.

If I understand this correctly, for a private issue we'll have 4 types of participants:

people whose visibility level is "all" (e.g., managers)
assignee of this issue (currently we can only assign to one developer)
reporter of this issue (the one who created this issue)
involvers of this issue (or call them subscribers)

If an involver chooses not to update the issue, she is essentially a watcher. So maybe these two (involve_user and watcher) can be somehow merged in this feature?

I think this feature would add much flexibility to private issues. Thanks to Bruno Medeiros to bring this up.

Ling Li wrote:

Thanks for implementing this. I am confused on one scenario though:

If a user doesn't have the privilege to see a private issue, but is added as a watcher to this private issue (say, by the manager), what would that user see (if her visibility_level is default)? Is it true that she will receive email updates but can't click/see the issue via the web interface?

That user won't see the issue and won't receive notifications even if he is added as a watcher. Maybe we should warn or even prevent from adding a watcher that is not allowed to view the issue.

I think if the feature requested by Bruno Medeiros is implemented, we won't worry about this any more.

Actions #20

Updated by Bruno Medeiros over 13 years ago

Jean-Philippe Lang wrote:

Bruno Medeiros wrote:

Jean-Philippe, do you think it's a good idea to create a "Involve" mechanism, that would be very similar to watch mechanism? So roles with 'involve_user' permission can add someone to the private issue, in a similar way people with 'add_watcher' permission add a watcher today.

This may be a feature to consider for a future release.

Feature request created: #8488

Actions #21

Updated by Frank Helk over 13 years ago

Just a question about the permission:

"default => all public issues and private issues created by or assigned to the user"

Does that include user that are attached to the issue as watcher, or is it strict "creator/assignee" ?

Actions #22

Updated by Bruno Medeiros over 13 years ago

Frank Helk :

Does that include user that are attached to the issue as watcher, or is it strict "creator/assignee" ?

Does NOT include, please read the comments above and ticket #8488.

Actions #23

Updated by Tory Wolf almost 11 years ago

I think it would be great to add new option in the role settings:

  • group => only issues inside the group

If this option is chosen, users who have this role can see only the issues inside their group.

Actions #24

Updated by Bruno Medeiros over 10 years ago

Tory Wolf wrote:

I think it would be great to add new option in the role settings:

  • group => only issues inside the group

If this option is chosen, users who have this role can see only the issues inside their group.

I don't understand, how do you know the group of an issue?
Besides that, you need to create a new issue with your feature request. Posting on a closed issue is very likely to be ignored.

Actions #25

Updated by Go MAEDA over 9 years ago

  • Has duplicate Feature #6331: Give a role a permission to view/edit only his tickets added
Actions

Also available in: Atom PDF