Feature #8488

Create an 'Involve' mechanism to private issues

Added by Bruno Medeiros almost 6 years ago. Updated 2 months ago.

Status:NewStart date:
Priority:NormalDue date:
Assignee:-% Done:

0%

Category:Issues
Target version:Candidate for next major release
Resolution:

Description

As requested by some people (#7414#note-16, #7412#note-3, and so on), sometimes we need to involve someone that cannot access an issue by "default rules". It can happen, for example, when a customer send a problem via email and we need to create a Redmine issue ourself, and give this customer access to the ticket.

I asked Jean-Phillipe on #7412#note-2 to extend the visibility of an issue to observers, and some people liked it, but it was not done because observe mechanism was designed for notification purposes (I now I agree it is not good, that's why I'm creating this feature request).

So my request is:
Create a involve mechanism where some roles can add people in an issue, in a very similar way they add an observer, and the added users have access to the issue the were involved.

private_issue_watchers.diff Magnifier - Patch to allow users to be added as watchers to private issues and to (2.24 KB) Justin Hahn, 2011-07-22 19:58

private_issue_watchers_FIXED.diff Magnifier (2.78 KB) Justin Hahn, 2011-07-28 17:48

private_issue_watchers_FIXED_1.3.diff Magnifier - patch ported to branch 1.3-stable (2.94 KB) Bruno Medeiros, 2011-12-09 14:10

private_issue_watchers_FIXED_1.4.diff Magnifier (2.73 KB) Daniele Palumbo, 2012-06-13 16:50

redmine-2-0.zip - Fix for redmine 2.x just copy them and set running as daemon and 664 (12 KB) Francesco Trigger, 2012-07-20 17:06

private_issue_watchers_FIXED_2.1.diff Magnifier (3.02 KB) Abdul Halim Mat Ali, 2012-09-21 08:49

private_issue_watchers_2.2.diff Magnifier (2.91 KB) Justin Hahn, 2013-02-28 20:11

private_issue_watchers_2.2_FIXED.diff Magnifier (3.09 KB) Justin Hahn, 2013-03-02 05:20

private_issue_watchers_2.2_FIXED_2.diff Magnifier (3.09 KB) Stanislav Židek, 2013-03-06 09:50

private_issue_watchers_2.2_FIXED_3.diff Magnifier (2.3 KB) Justin Hahn, 2013-03-06 14:18

private_issue_watchers_2.2_FIXED_4.diff Magnifier (2.14 KB) Justin Hahn, 2013-03-06 14:47

private_issue_watchers_2.2_FIXED_5.diff Magnifier (2.58 KB) Justin Hahn, 2013-03-07 16:41

private_issue_watchers_2.2_FIXED_6.diff Magnifier (2.59 KB) Krzysztof Wosinski, 2014-04-08 08:02

private_issue_watchers_3.1.x.diff Magnifier (3.32 KB) Hang Xie, 2015-11-19 06:58


Related issues

Related to Redmine - Feature #7414: Private issues Closed 2011-01-22
Related to Redmine - Feature #7412: Add an issue visibility level to each role Closed 2011-01-22
Related to Redmine - Defect #11888: No e-mail notification for non-members who are watchers New
Related to Redmine - Defect #12945: watcher can't see this issue from My Page-Watched issues Closed
Related to Redmine - Feature #12666: Involvement boolean for Custom Field 'User' type New
Related to Redmine - Feature #13512: Add a way to make specific issues visible to a user New
Related to Redmine - Feature #13533: Concept for controlling visibility of users New
Related to Redmine - Feature #285: Tracker role-based permissioning Closed
Related to Redmine - Feature #16845: Add permission rule to allow watchers can edit issues New
Related to Redmine - Defect #22977: A project member has no access and gets no notification, ... New
Related to Redmine - Patch #23546: Issue visibility "watched by, created by or assigned to" ... New
Duplicated by Redmine - Feature #9330: Watchers can not see the ticket status, if their role is ... Closed 2011-09-27
Duplicated by Redmine - Defect #10173: Private bugs are not visible to watchers Closed 2012-02-08 2012-02-17
Duplicated by Redmine - Defect #12584: Watchers on Private Issues Closed
Duplicated by Redmine - Feature #11718: If you add a watcher to an issue, they should have rights... Closed
Duplicated by Redmine - Feature #13828: when users can only see their own issues; give watchers t... Closed
Duplicated by Redmine - Patch #14318: Watchers Alerted To Changes But Cannot See Issues (potent... Closed

History

#1 Updated by Etienne Massip almost 6 years ago

  • Category set to Issues

#2 Updated by Anton Nepomnyaschih almost 6 years ago

Also, it would be cool to set visibility level for each comment, like in JIRA, where you can write somethings to a specific users group.

#3 Updated by Bruno Medeiros almost 6 years ago

Anton Nepomnyaschih wrote:

Also, it would be cool to set visibility level for each comment, like in JIRA, where you can write somethings to a specific users group.

Anton, There is already a feature request for that, #1554. Let's try don't mix requests.

#4 Updated by Anton Nepomnyaschih almost 6 years ago

Oh, you are right! Sorry!

#5 Updated by Terence Mill almost 6 years ago

+1

#6 Updated by Roman E. almost 6 years ago

+1

ty!

#7 Updated by Dmitry Salashnik almost 6 years ago

+1

#9 Updated by Terence Mill almost 6 years ago

There is a CCC PLugin, which can add email adresses to be notified beyond redmine user base.

#10 Updated by Pavel Konstantinov almost 6 years ago

Terence Mill wrote:

There is a CCC PLugin, which can add email adresses to be notified beyond redmine user base.

This comment has no relation to the issue. This issue not about notification, but about issue access control

#11 Updated by Justin Hahn almost 6 years ago

While I've read the commentary about how watchers are the wrong mechanism for this, I needed this functionality to upgrade my company to v1.2.1 and meet our privacy needs. We'd previously been using the 'view own issues' patch in an old release which works roughly the same way.

Consequently, we cooked up this patch. It over-rides the addable_watcher_users method from acts_as_watchable to allow any user who can view issues to be added as a watcher, and then adds watchers of the issue to the visible named scope and the visible? method so that they can see operate on the issue.

I don't expect this patch to be accepted but if, like me, you can't wait another 4 years for this to get straightened out then maybe this will help you.

I've only tested this in the context of my environment, so I can't promise it won't do terrible things to yours. I'm not Rails wizard, but I think it's pretty low impact. Your Mileage May Vary. If it breaks, you get to keep both parts.

#12 Updated by mm MMY over 5 years ago

Hello
After patching some problems happened :
Simple users cant access Activity page and give 500 Internal Error .
so i redo patch changes and all things work true .

#13 Updated by Justin Hahn over 5 years ago

I have updated the patch for allowing watchers to see private issues to fix an issue with the Activity page -- there was a reference to Issue.visible_conditions in the journal model (which is related to the Activity page) which requires an include of the :watchers relation.

This updated patch should fix the issue with Activity giving a 500 Error.

#14 Updated by mm MMY over 5 years ago

Well done .
Thanks .

#15 Updated by Colin Mollenhour over 5 years ago

+1

In the meantime, thanks for sharing your patch, Justin!

#16 Updated by Alessio Cassibba over 5 years ago

Thank you Bruno for sharing this, saved me a lot of time and effort.
Would be nice to see it implemented upstream as well.

#17 Updated by Bruno Medeiros over 5 years ago

Alessio Cassibba wrote:

Thank you Bruno for sharing this, saved me a lot of time and effort.

I'm not the patch author, but you're welcome anyway :) The patch has been submitted by Justin Hahn.

#18 Updated by Martin G over 5 years ago

+1

#19 Updated by Francesco Trigger over 5 years ago

Justin Hahn wrote:

I have updated the patch for allowing watchers to see private issues to fix an issue with the Activity page -- there was a reference to Issue.visible_conditions in the journal model (which is related to the Activity page) which requires an include of the :watchers relation.

This updated patch should fix the issue with Activity giving a 500 Error.

Thanks Justin!! exactly what i was searching for!!! :)

#20 Updated by Francesco Trigger over 5 years ago

Justin Hahn wrote:

I have updated the patch for allowing watchers to see private issues to fix an issue with the Activity page -- there was a reference to Issue.visible_conditions in the journal model (which is related to the Activity page) which requires an include of the :watchers relation.

This updated patch should fix the issue with Activity giving a 500 Error.

But now if the assignee is changed, the old assignee gets an 403 error if he is only allowed to see tickets as an assignee or ticket issuer.
Is there a way to redirect the user to the issues page after altering the ticket assignee?

#21 Updated by Francesco Trigger over 5 years ago

Is there a way to add the one updating the issue automatically as a watcher?

#22 Updated by Bruno Medeiros over 5 years ago

I guess I could port this patch to the 1.3-stable branch, but couldn't test yet. If someone could give some feedback on it, I would appreciate. :)

#23 Updated by Francesco Trigger over 5 years ago

Bruno Medeiros wrote:

I guess I could port this patch to the 1.3-stable branch, but couldn't test yet. If someone could give some feedback on it, I would appreciate. :)

Hey Bruno,

i tested it on 1.3 and it seems to work like a charme :) Thank you very much. Only question i have, is it possible to send an email also out to the watcher, when he was added to the issue or the issue was updated?

Thank you very much for your work!! :)

Francesco

#24 Updated by Bruno Medeiros over 5 years ago

Francesco Trigger wrote:

i tested it on 1.3 and it seems to work like a charme :) Thank you very much. Only question i have, is it possible to send an email also out to the watcher, when he was added to the issue or the issue was updated?

I don't believe we can send email when adding the observer/watcher, but redmine is supposed to send an email when the issue is updated if the proper config is set on the administration options.

Thank you very much for your work!! :)

You're welcome, but I'm not the author of the patch, just ported it. We all need to thank Justin Hahn! :)

#25 Updated by Anton Tsapov about 5 years ago

mm MMY wrote:

After patching some problems happened :
Simple users cant access Activity page and give 500 Internal Error .

If I understand correctly, I have the same problem.
I use last patch: private_issue_watchers_FIXED_1.3.diff, but simple users can't access to links like this /projects/project_name/issues/report.

The error, that I've got:

Mysql::Error: Unknown column 'watchers.user_id' in 'where clause': select    s.id as status_id, 
                                                s.is_closed as closed, 
                                                j.id as tracker_id,
                                                count(issues.id) as total 
                                              from 
                                                  issues, projects, issue_statuses s, trackers j
                                              where 
                                                issues.status_id=s.id 
                                                and issues.tracker_id=j.id
                                                and issues.project_id=projects.id
                                                and (((projects.id = 2) AND (projects.status=1 AND projects.id
 IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking'))) AND (projects.id IN (1,43,34,65)
 OR ((projects.is_public = 1) OR  (projects.id IN (SELECT projects.id
                                 FROM projects, project_non_member_users
                                 WHERE projects.id = project_non_member_users.project_id
                                 AND (project_non_member_users.user_id = 886
                                  OR project_non_member_users.group_id IN (240,241,293,467,573,638,655,659,695,711,718,804,854))))
 AND ((issues.is_private = 0 OR issues.author_id = 886 OR issues.assigned_to_id
 IN (886,240,241,293,467,573,638,655,659,695,711,718,804,854) OR watchers.user_id = 886))) OR projects.id IN (13)))
                                              group by s.id, s.is_closed, j.id

Backtrace:

C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract_adapter.rb:227:in `log'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/mysql_adapter.rb:324:in `execute'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/mysql_adapter.rb:639:in `select'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract/database_statements.rb:7:in
 `select_all_without_query_cache'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract/query_cache.rb:81:in `cache_sql'
C:/Ruby/lib/ruby/gems/1.8/gems/activerecord-2.3.14/lib/active_record/connection_adapters/abstract/query_cache.rb:60:in `select_all'
D:/Draft/redmine_svn/app/models/issue.rb:1073:in `count_and_group_by'
D:/Draft/redmine_svn/app/models/issue.rb:751:in `by_tracker'
D:/Draft/redmine_svn/app/controllers/reports_controller.rb:31:in `issue_report'

And when I run tests, some of them give the same errors.

#26 Updated by Florian Steiger almost 5 years ago

The patch 1.3 dont work for our updated Redmine 1.4.1 (from 1.2.1).
Are there any solutions?

Thanks for any hints.

#27 Updated by William Roush almost 5 years ago

+1, this is a major requirement when dealing with a part of the company that should only have access to issues that you've assigned to as watchers when they may only have "view own issues" permissions.

#28 Updated by Max Schwer almost 5 years ago

We need also a solution for 1.4.1
Is there somebody we can hire to solve this problem?

#29 Updated by Bruno Medeiros almost 5 years ago

Max Schwer wrote:

We need also a solution for 1.4.1
Is there somebody we can hire to solve this problem?

I would offer myself if I were something more than a rails noob.. :P

#30 Updated by Vadim Goncharov almost 5 years ago

Max Schwer, I successfuly applied code from "private_issue_watchers_FIXED_1.3.diff" in Redmine 2.0.1 (just manually copy-paste in app/model/issue.rb and app/model/journal.rb). And now watchers can view private issues. Thanks to Justin Hahn and Bruno Medeiros.

#31 Updated by William Roush almost 5 years ago

Vadim Goncharov wrote:

Max Schwer, I successfuly applied code from "private_issue_watchers_FIXED_1.3.diff" in Redmine 2.0.1 (just manually copy-paste in app/model/issue.rb and app/model/journal.rb). And now watchers can view private issues. Thanks to Justin Hahn and Bruno Medeiros.

How stable is this? What is the process to get this steamed into the main Redmine branch?

I guess we could pull this out into a plugin, but it would be nicer to have Redmine support this idea natively.

#32 Updated by Daniele Palumbo almost 5 years ago

I have just uploadaded the diff with 1.4.1 version.
I would really love this small improvement to be pushed into mainstream.

#33 Updated by Bruno Medeiros almost 5 years ago

Applied ok on current 1.4-stable, didn't fully tested yet. Thanks!

#34 Updated by Terence Mill almost 5 years ago

Does the inviolved user have any rights in redmine or project? I assime that the user at least mus be registered. Or is this possible with adding an email the owber gest one time links?

#35 Updated by Bruno Medeiros almost 5 years ago

William Roush wrote:

How stable is this? What is the process to get this steamed into the main Redmine branch?

As explained on the second paragraph of the description, this approach will not be accepted on Redmine. I personally see one big downside now (I defended this approach in the past): If an user that gained access to the ticket by the observer mechanism clicks 'Unwatch', he irreversibly looses access to the ticket. That's not acceptable and that's why I created this ticket to ask for a 'Involve mechanism' very similar to the Observe mechanism.

I guess we could pull this out into a plugin, but it would be nicer to have Redmine support this idea natively.

This is more reasonable for now, but I don't know how to create plugins.

#36 Updated by Maxim Nikolaevich almost 5 years ago

Bruno Medeiros wrote:

If an user that gained access to the ticket by the observer mechanism clicks 'Unwatch', he irreversibly looses access to the ticket. That's not acceptable and that's why I created this ticket to ask for a 'Involve mechanism' very similar to the Observe mechanism.

Ok, let suppose feature 'Involve' will be done.
What should redmine do when some customer ask to uninvolve from issue?
I suppose he should loose access to the ticket. Should he?
to stop confuse only one additional feature required to be added to attached patch:

When customer click "unwatch" redmine should check - this customer loose access after this action and if so - show new additional dialogue like this:
Attention! unwatch will looses access to the ticket. Continue?

So i think redmine should use "Watcher mechanism" and should not do new "Involve mechanism".

#37 Updated by Bruno Medeiros almost 5 years ago

Maxim Nikolaevich wrote:

Ok, let suppose feature 'Involve' will be done.
What should redmine do when some customer ask to uninvolve from issue?
I suppose he should loose access to the ticket. Should he?

I think that involved should not uninvolve himself.

to stop confuse only one additional feature required to be added to attached patch:

When customer click "unwatch" redmine should check - this customer loose access after this action and if so - show new additional dialogue like this:
Attention! unwatch will looses access to the ticket. Continue?

So i think redmine should use "Watcher mechanism" and should not do new "Involve mechanism".

And what if you want to involve someone, but don't want to have this person being notified by email? There is no way to do that using only one mechanism.

I see your point, and that was my point before, but I can understand why Jean-Phillipe don't like it. Using something that was designed for notification purposes to access control is kind of a hack and will have its limitations.

I like this patch, and I'm using this on my redmine instance, and I say thanks to the author, but I understand if it's no integrated at any time.

#38 Updated by Francesco Trigger almost 5 years ago

  • Assignee set to Mischa The Evil

Is there a fix for 2.0 ?

#39 Updated by Francesco Trigger almost 5 years ago

Francesco Trigger wrote:

Is there a fix for 2.0 ?

I tried to modify the files like in Redmine 1.x but i get this trying to access redmine in the production.log.

Connecting to database specified by database.yml
Creating scope :active. Overwriting existing method User.active.
Creating scope :open. Overwriting existing method Version.open.
DEPRECATION WARNING: The InstanceMethods module inside ActiveSupport::Concern will be no longer included automatically. Please define instance methods directly in CollectiveIdea::Acts::NestedSet::Model instead. (called from include at /opt/redmine/apps/redmine/htdocs/lib/plugins/awesome_nested_set/lib/awesome_nested_set/awesome_nested_set.rb:58)
OpenIdAuthentication.store is nil. Using in-memory store.

#41 Updated by Bruno Medeiros almost 5 years ago

  • Assignee deleted (Mischa The Evil)

Francesco Trigger, could you provide a patch? It's not a good idea override whole files since they change over time.

#42 Updated by Maxim Nikolaevich over 4 years ago

I'm sorry for long time answer

Bruno Medeiros wrote:

And what if you want to involve someone, but don't want to have this person being notified by email? There is no way to do that using only one mechanism.

Can you describe real case how it can be: 'Guy was involved but should not notified' ?
current settings about email notification here says:
1. For any event on all my projects
2. Only for things I watch or I'm involved in
3. Only for things I am assigned to
...

So if you are involved - you should receive emails - it's like you watch.
If you watcher - you are involved.
It's easy to understand and easy to code.

In other way let me suppose involved and watched are different things.
I see many problems in this way like:
1. Guy is watcher but has no permission - somebody think they receive message but actually not
2. It's possible to set watchers in time of creating issue but probably watcher has no permissions...

So i see only one issue - 'unstar' with lose permission - but my solution i mention in comment above

In other words:
What is goal for involving somebody?
Goal is to notify him when hidden issue is changed. Goal is to allow him see hidden issue changes.
So watcher = involved i think

Let me know if i miss something

#43 Updated by Bruno Medeiros over 4 years ago

Maxim Nikolaevich wrote:

In other words:
What is goal for involving somebody?
Goal is to notify him when hidden issue is changed. Goal is to allow him see hidden issue changes.
So watcher = involved i think

Let me know if i miss something

Yes, you missed. Involve someone doesn't necessarily mean that you want this person being notified by email. You may want to let this user only access an issue when he wants to, not notifying him every time the issue is changed. You're simplifying things to much considering that involve = observe.

#44 Updated by Maxim Nikolaevich over 4 years ago

Bruno Medeiros wrote:

Involve someone doesn't necessarily mean that you want this person being notified by email. You may want to let this user only access an issue when he wants to, not notifying him every time the issue is changed.

If somebody assign issue to you it means you will be notified every time about changing in this issue. Is it problem? I think no.
So when somebody set you as watcher - you also will be notified about every changing in this issue.
I can't to find real usacase when i need to involve sombody to issue (from closed project!) without notifying them about changing issue.
If i assign issue from closed project to some guy then him will be notified about every changes, right?

#45 Updated by Pavel Konstantinov over 4 years ago

I completely agree with Bruno Medeiros Maxim Nikolaevich. Watcher = involved, involve = observe.
For my project this feature is key feature. Only inability to give personal access to private issues blocks upgrade of Redmine from 1.3 to 2.x (with lot of fixes and new features).
I can not organize customer's workflow without this feature.

Dear developers, can you summarize status of this issue?

#46 Updated by Maxim Nikolaevich over 4 years ago

I completely agree with Bruno Medeiros. Watcher = involved, involve = observe.

Bruno Medeiros has different point of view. Bruno Medeiros tell ut these should be different settings. So it's strange that you are agree but tell my point of view about this things.
What you want to tell really:
1. You agree with me
2. You think watcher should be not equal involved, and involve shuuld be not equal observe.

Dear developers, can you summarize status of this issue?

I tottaly agree. Dear developers please give us your plans about this issue.

#47 Updated by Pavel Konstantinov over 4 years ago

Maxim, you are right. I just copied a wrong name to my post.
So, my main idea is "Watcher = involved, involve = access". I see no reason to "watch" something and have no access to it but gets only notification mail about it with, actually, all same information, but packed in e-mails.
Or "be involved" but get no notification mails.
"Be envolved" mostly means "have access and get notifications" and Redmine should provide it in this way.

#48 Updated by Daniele Palumbo over 4 years ago

Bruno Medeiros wrote:

Francesco Trigger, could you provide a patch? It's not a good idea override whole files since they change over time.

+1.

i have "deploy overwriting" mode.

thanks,
Daniele

#49 Updated by Abdul Halim Mat Ali over 4 years ago

Attached is the patch for version 2.1.

The original patch resolve not only watchers for private issue.
It is also resolve, watchers not able to view non-public projects issues when they are path of the watchers list.

I am wondering why Redmine developers are not integrating this patch.
Does it cause any other bug or slow down the query?

#50 Updated by Kris Lou over 4 years ago

+1.

This would significantly aid the use of Redmine in a Help Desk situation. Honestly, the "view Issues Created by or Assigned to" should include "or Watching."

#51 Updated by ysbranddoug andeson over 4 years ago

  • Assignee set to Jim Mulholland

#52 Updated by Etienne Massip over 4 years ago

  • Assignee deleted (Jim Mulholland)

#53 Updated by chockiquin John over 4 years ago

  • Assignee set to Chaoqun Zou

#54 Updated by Etienne Massip over 4 years ago

  • Assignee deleted (Chaoqun Zou)

#55 Updated by theylory aifseng over 4 years ago

  • Assignee set to Mischa The Evil

#100 Updated by Bruno Medeiros over 4 years ago

Maxim Nikolaevich wrote:

I completely agree with Bruno Medeiros. Watcher = involved, involve = observe.

Bruno Medeiros has different point of view. Bruno Medeiros tell ut these should be different settings. So it's strange that you are agree but tell my point of view about this things.
What you want to tell really:
1. You agree with me
2. You think watcher should be not equal involved, and involve shuuld be not equal observe.

Men, I believe you're missing the main point here. I created this ticket because Redmine developers rejected the idea of using observe mechanism to do access control.
I said it before and I'll say it now again: As user, I agree with you and I use the patch that is being maintained here. Using the already existing observe mechanism to involve people is reasonable.
But, as a developer, I can understand why Redmine developers don't want to integrate this patch.

Please, let's stop asking something that has already been rejected by Redmine developers. it will only bother them.

Dear developers, can you summarize status of this issue?

I tottaly agree. Dear developers please give us your plans about this issue.

The status is implicit: Implement a involve mechanism, apart from observer mechanism, and it can be considered to be integrated on Redmine.
Or we can maintain this patch in parallel forever (many thanks for who is doing that now, I'm a very happy user of this patch :) ).

#101 Updated by Toshi MARUYAMA over 4 years ago

  • Assignee deleted (Mischa The Evil)

#102 Updated by Ton Nguyen over 4 years ago

Hi,

After applying this patch, I got the following error when trying to access page 'http://myserver/projects/<project_id>/issues/report'

ActiveRecord::StatementInvalid (Mysql::Error: Unknown column 'watchers.user_id' in 'where clause': select s.id as status_id,
s.is_closed as closed,
j.id as tracker_id,
count(issues.id) as total
from
issues, projects, issue_statuses s, trackers j
where
issues.status_id=s.id
and issues.tracker_id=j.id
and issues.project_id=projects.id
and (((projects.id = 84) AND (projects.status=1 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking'))) AND (projects.id IN (86,89) OR (projects.id IN (84,80) AND ((issues.is_private = 0 OR issues.author_id = 3 OR watchers.user_id = 3 OR issues.assigned_to_id IN (3,5))))))
group by s.id, s.is_closed, j.id):
app/models/issue.rb:1099:in `count_and_group_by'
app/models/issue.rb:789:in `by_tracker'
app/controllers/reports_controller.rb:31:in `issue_report'

But when I access this page with admin account, I do not get this error. I am really appreciate your help!

Regards,

#103 Updated by Maxim Nikolaevich over 4 years ago

Bruno Medeiros wrote:

I created this ticket because Redmine developers rejected the idea of using observe mechanism to do access control.

I saw #7412-13 discussion

Jean-Philippe Lang wrote:
A user who unwatches a private issue would lost access to it. It may be quite confusing for many users.

So developers rejected this patch because, it does not solve one very important usecase (which i describe above):

When customer click "unwatch" redmine should check - this customer loose access after this action and if so - show new additional dialogue like this:
Attention! unwatch will looses access to the ticket. Continue?

So i agree without additional dialogue this feature should not be used in production. (like this patch allow)
But i think this dialogue not so hard to code

#104 Updated by Maxim Nikolaevich over 4 years ago

hm... this page has 'Google Page Rank'=3
So google see how this feature is important :)

#105 Updated by Bruno Medeiros over 4 years ago

Maxim Nikolaevich wrote:

So developers rejected this patch because, it does not solve one very important usecase (which i describe above):

When customer click "unwatch" redmine should check - this customer loose access after this action and if so - show new additional dialogue like this:
Attention! unwatch will looses access to the ticket. Continue?

So i agree without additional dialogue this feature should not be used in production. (like this patch allow)
But i think this dialogue not so hard to code

This isn't the only issue with the current patch/approach. I will list all the problems I see now (again):

  1. Unwatch make user irreversible lose access to ticket - This is the first issue people first realized, and maybe the biggest issue in this patch. And I don't think create a dialog fixes the problem. Make a confirmation dialog would create a big inconsistency: If I click unwatch in a ticket that I have access granted by "normal" rules, I turn off email notification for this ticket. If I do that with a ticket that I'm involved, I lose access? That doesn't make sense at all.
  2. Be involved not equals watch - This is a fact. If they seem the same for you, you need less from Redmine than other people would. A watcher needs to be involved, but involved people don't necessarily need to watch. Like I said before: Involve someone doesn't necessarily mean that you want this person being notified by email. You may want to let some user only access an issue when he wants to, not notify this user every time the issue is changed. You're simplifying things to much considering that involve = observe.
  3. Permission control needs to be separated - We have today 3 permissions: Add watcher, Remove watcher, See watchers list. Using observe mechanism to involve people implies that every role that is able to add/remove watchers will be able to involve/uninvolve people. This would be a design failure. We need separated permissions for involve.
  4. Watch mechanism was designed for notification purposes - And when I say mechanism I don't mean only the option to watch/unwatch a ticket, I mean this combo on the ticket screen, plus all the permissions to allow different roles to add and remove watchers, plus all tables in the database, mail senders, etc. All this was designed thinking of notifying people with emails about changes, not control access. If Redmine develorpers decide to use this mechanism to control access to tickets, this could bring problems to the project in the future.

And before people start to say again that I'm against this patch: I'm not against this patch, I'm a very happy and thankful user of it. I just understand why Redmine developers refuse to integrate it.

#106 Updated by Francesco Trigger over 4 years ago

Abdul Halim Mat Ali wrote:

Attached is the patch for version 2.1.

The original patch resolve not only watchers for private issue.
It is also resolve, watchers not able to view non-public projects issues when they are path of the watchers list.

I am wondering why Redmine developers are not integrating this patch.
Does it cause any other bug or slow down the query?

Hey,

thanks for the new patch, i tried it, but it does not work :(
Any ideas?

Francesco

#107 Updated by Abdul Halim Mat Ali over 4 years ago

I have tried it on Redmine version 2.1.0.
I don't know whether it will work on other version or on the latest svn checkout.

Francesco Trigger wrote:

Abdul Halim Mat Ali wrote:

Attached is the patch for version 2.1.

The original patch resolve not only watchers for private issue.
It is also resolve, watchers not able to view non-public projects issues when they are path of the watchers list.

I am wondering why Redmine developers are not integrating this patch.
Does it cause any other bug or slow down the query?

Hey,

thanks for the new patch, i tried it, but it does not work :(
Any ideas?

Francesco

#108 Updated by Christophe Badoit over 4 years ago

+1

I would love this feature, although I understand this patch would break a lot of currently used workflow.

Thanks for the patch, it works well with 2.1.

#109 Updated by Abdul Halim Mat Ali over 4 years ago

Christophe Badoit wrote:

+1

I would love this feature, although I understand this patch would break a lot of currently used workflow.

Thanks for the patch, it works well with 2.1.

What kind of workflow it will break? I am curious.

#110 Updated by Adnan Topçu over 4 years ago

+1

And also, there is a need for redmine 2.2
I was tried to manual update but there was not successfully. :(

#111 Updated by Tolga Yaman over 4 years ago

Is there a plan for integrating this patch to stable releases?

#112 Updated by Jinyi Cui about 4 years ago

+1
I met the same question, add a watcher means u want notify the issue's change to the watcher.

#113 Updated by Daniel Felix about 4 years ago

  • Target version set to Candidate for next major release

Because many people seem to need this. I propose to set this as a candidate for the next major release. Maybe Jean-Philippe would disagree, but this is just a proposal. :-)

#114 Updated by Joshua DeClercq about 4 years ago

As I suggested in #12666, I think a clean way to do this would be, when creating a custom field and setting the type to 'user', having a check box for enabling involvement in the issue. Coupled with multi-select, this lets you have as much or as little control over how users are involved in an issue as you need.

#115 Updated by Justin Hahn about 4 years ago

I have updated the patch for v2.2.3 of redmine. It appears to be working fine for me. Please let me know if you experience problems with it on 2.2

#116 Updated by Justin Hahn about 4 years ago

It turns out that patch has a subtle defect. Attempting to sort on Assignee or any other user-based column would result in no data being returned. After much debugging, I think I've found a resolution. For the technically inclined, I've moved from eager loading the :watchers association to using an explicit LEFT OUTER JOIN via a :join parameter/method.

It's not obvious to me at all why this was breaking with watchers as an include, and I suspect the way I've done this is a touch ugly (It's certainly not very DRY), but it works at least. I really wish the proper "Involve" functionality were in place so we could end of life this tweak.

Anyhow, corrected patch attached.

#117 Updated by Stanislav Židek about 4 years ago

Justin Hahn wrote:

It turns out that patch has a subtle defect. Attempting to sort on Assignee or any other user-based column would result in no data being returned.

I tried to apply your patch and got an error when trying to see a project or "My page":

(0.5ms)  SELECT COUNT(DISTINCT `issues`.`id`) FROM `issues` LEFT OUTER JOIN `projects` ON `projects`.`id` = `issues`.`project_id` LEFT OUTER JOIN `issue_statuses` ON `issue_statuses`.`id` = `issues`.`status_id` LEFT OUTER JOIN "watchers" ON "watchers"."watchable_id" = "issues"."id" AND "watchers"."watchable_type" = 'Issue' WHERE `issues`.`assigned_to_id` IN (11, 17, 24, 85) AND (((projects.status <> 9 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking')) AND ((projects.id IN (73,49,12,77) AND ((issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR (projects.id IN (66,72) AND ((issues.is_private = 0 OR issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR (projects.is_public = 1 AND ((issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR projects.id IN (72) OR (projects.id IN (69,68,64,57,63,71,12,70,66,72,3) AND ((issues.is_private = 0 OR issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85))))))) AND (issue_statuses.is_closed = 0)

Mysql::Error: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '"watchers" ON "watchers"."watchable_id" = "issues"."id" AND "watchers"."watchabl' at line 1: SELECT COUNT(DISTINCT `issues`.`id`) FROM `issues` LEFT OUTER JOIN `projects` ON `projects`.`id` = `issues`.`project_id` LEFT OUTER JOIN `issue_statuses` ON `issue_statuses`.`id` = `issues`.`status_id` LEFT OUTER JOIN "watchers" ON "watchers"."watchable_id" = "issues"."id" AND "watchers"."watchable_type" = 'Issue' WHERE `issues`.`assigned_to_id` IN (11, 17, 24, 85) AND (((projects.status <> 9 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking')) AND ((projects.id IN (73,49,12,77) AND ((issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR (projects.id IN (66,72) AND ((issues.is_private = 0 OR issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR (projects.is_public = 1 AND ((issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85)))) OR projects.id IN (72) OR (projects.id IN (69,68,64,57,63,71,12,70,66,72,3) AND ((issues.is_private = 0 OR issues.author_id = 11 OR watchers.user_id = 11 OR issues.assigned_to_id IN (11,17,24,85))))))) AND (issue_statuses.is_closed = 0)

I suppose there is a problem because of double-quotes (") instead of back quotes (`) around some table/column names:

LEFT OUTER JOIN "watchers" ON "watchers"."watchable_id" = "issues"."id" AND "watchers"."watchable_type" = 'Issue'

I tried to modify your patch according to this (attaching). I will keep testing it.

Notes:
  • I am less than beginner with Ruby/Rails, I work with it only from sysadmin point of view. Therefore, I might have done some incredibly stupid things because of misunderstanding. Feel free to correct me.
  • I am using mysql database backend. I have no idea if the changes might break if you use other database.

#118 Updated by Justin Hahn about 4 years ago

Stanislav, thanks for the report. However, it turns out there are other problems with the patch I put together. I use/test on postgres, so the issue you experienced must be due to that difference. Regardless, the change I put together is bad. It will break pagination on large issues lists in that pages will have fewer results than expected and you'll end up with inaccessible issues. (This is because the join that I added causes the query Rails/Redmine issues to the database to return duplicates)

So, instead, I've modified the patch to work differently. Instead of attempting to :join or :include the watchers relation, I've gone with fetching a list of watched issue ids by the given user, and then adding those issue ids to the WHERE clause on the SQL conditions. This seems to work much better, and is less invasive (in particular we no longer have to modify the app/models/journal.rb file)

I think this updated patch may solve both our issues. To be honest, I'm surprised past versions of this patch didn't have similar issues. Make sure to apply this against the pristine sources, and not against a previously patched version of the code. (revert app/models/issue.rb and app/models/journal.rb)

Patch attached.

#119 Updated by Justin Hahn about 4 years ago

I hate to update my own patch in less than an hour, but I found a slightly cleaner way to do what I did. So, alas, here is FIXED_4. It's not, functionally, any different than FIXED_3 but the code is a bit cleaner.

#120 Updated by Sergey Norv about 4 years ago

I use redmine 2.2.3

Environment:
  Redmine version                          2.2.3.stable
  Ruby version                             1.9.2 (x86_64-linux)
  Rails version                            3.2.12
  Environment                              production
  Database adapter                         Mysql2

After install the patch (private_issue_watchers_2.2_FIXED_4.diff) when the page opens with a list of problems some users displays 500 error.
log:
Started GET "/projects/5135p?jump=overview" for 172.19.32.97 at 2013-03-07 09:57:57 +0400
Processing by ProjectsController#show as HTML
  Parameters: {"jump"=>"overview", "id"=>"5135p"}
  Current user: sapatoit (id=89)
Redirected to http://172.19.32.47:3000/projects/5135p
Completed 302 Found in 10ms (ActiveRecord: 1.1ms)
Started GET "/projects/5135p" for 172.19.32.97 at 2013-03-07 09:57:57 +0400
Processing by ProjectsController#show as HTML
  Parameters: {"id"=>"5135p"}
  Current user: usertest(id=89)
Completed 500 Internal Server Error in 67ms

ActiveRecord::StatementInvalid (Mysql2::Error: You have an error in your SQL syntax; check the manual that corresponds to your MariaDB server version for the right syntax to use near ')))) OR (projects.id IN (14,3) AND ((issues.author_id = 89 OR issues.assigned_to' at line 1: SELECT COUNT(DISTINCT `issues`.`id`) AS count_id, tracker_id AS tracker_id FROM `issues` LEFT OUTER JOIN `projects` ON `projects`.`id` = `issues`.`project_id` LEFT OUTER JOIN `issue_statuses` ON `issue_statuses`.`id` = `issues`.`status_id` WHERE (((projects.status <> 9 AND projects.id IN (SELECT em.project_id FROM enabled_modules em WHERE em.name='issue_tracking')) AND ((projects.is_public = 1 AND ((issues.author_id = 89 OR issues.assigned_to_id IN (89,97) OR issues.id IN ()))) OR (projects.id IN (14,3) AND ((issues.author_id = 89 OR issues.assigned_to_id IN (89,97) OR issues.id IN ()))) OR (projects.id IN (14) AND ((issues.author_id = 89 OR issues.assigned_to_id IN (89,97) OR issues.id IN ())))))) AND (issue_statuses.is_closed = 0) AND ((projects.id = 14 OR (projects.lft > 7 AND projects.rgt < 8))) GROUP BY tracker_id):
  app/controllers/projects_controller.rb:156:in `show'

After removal of the patch, everything works fine.
How can I fix this?

#121 Updated by Justin Hahn about 4 years ago

Oh, interesting. I believe the problem is there are no issues being watched by those users. I don't have a good way to test this right now. Can you try this to verify for me?

Take one of the users with this issue and have them watch a single issue. If the problem goes away, I think I know how to fix it. If not, let me know.

#122 Updated by Justin Hahn about 4 years ago

OK, I've been able to reproduce in my environment. This patch should fix that issue. We now only insert the watched issues.id clause when there are actually watched issues for the user. Let me know if you run into anything else.

#123 Updated by Justin Hahn about 4 years ago

OK, I've been able to reproduce in my environment. This patch should fix that issue. We now only insert the watched issues.id clause when there are actually watched issues for the user. Let me know if you run into anything else.

#124 Updated by Stanislav Židek about 4 years ago

Justin, I tried your last patch and it seems to work (still using mysql).

Btw, I've also tried the original patch (private_issue_watchers_2.2.diff) and haven't been able to reproduce the problem. Can you tell me the exact way how to do that?

#125 Updated by Anton Nepomnyaschih about 4 years ago

Does the patch work with Redmine 2.3.0?

#126 Updated by Justin Hahn about 4 years ago

Given that 2.3.0 was just released two days ago, I'd say there's at best a 50/50 chance of it. Feel free to post an updated version if it doesn't.

#127 Updated by César Perales about 4 years ago

Justin Hahn, thank you for the patch , i tried it (private_issue_watchers_2.2_FIXED_5.diff) and it works when i create the issue but not when the issue its already created and watchers are added. Using redmine 2.2.3.

Works ok

#128 Updated by Anton Nepomnyaschih about 4 years ago

The patch seems working with 2.3.0.

#129 Updated by Massimo Rossello about 4 years ago

I've made a plugin for the 1.4.x version: http://www.redmine.org/plugins/redmine_extended_watchers

It also disables adding watchers foreign to the project. It seems weird to me the possibility to be watchers and not being able to inspect and be notified about some issue, in private projects.

Probably this aspect needs fix with public projects; any contribution is appreciated

#130 Updated by Bruno Medeiros almost 4 years ago

I've just upgraded my Redmine to 2.3 and installed the plugin. So far, so good!
One downside I see on the plugin approach is that some fragments of the core are copied in the plugin, and there will be no conflict if the core changes. Any thoughts on this?

#131 Updated by Adnan Topçu almost 4 years ago

Hello,
private_issue_watchers_2.2_FIXED_5.diff and redmine_extended_watchers plugin have same effect and they works well.
But watcher search function does not work during the adding new watcher when you use one of them ??

Environment:
Redmine version 2.2.3.stable
Ruby version 1.9.3 (x86_64-linux)
Rails version 3.2.12
Environment production
Database adapter Mysql2

#132 Updated by Toshi MARUYAMA about 3 years ago

  • Related to Feature #11718: If you add a watcher to an issue, they should have rights to view it. added

#133 Updated by Toshi MARUYAMA about 3 years ago

  • Related to deleted (Feature #11718: If you add a watcher to an issue, they should have rights to view it.)

#134 Updated by Toshi MARUYAMA about 3 years ago

  • Duplicated by Feature #11718: If you add a watcher to an issue, they should have rights to view it. added

#135 Updated by Konrad Baranowski about 3 years ago

Unfortunately after patching issue.rb on Redmine 2.5.0 stable I have an Internal Error 500 when I want to update issue. More strange is that after reverting changes, error still appears. Apart of this error, patch doesn't make issues visible for watchers.

#136 Updated by Krzysztof Wosinski about 3 years ago

Hi,

I had the same error as Konrad on my Redmine 2.4.2 (working on Bitnami VM). Updating the patch helped. I attach the patch working in my 2.4.2 version (maybe it will also work in 2.5.0?).

#137 Updated by Konrad Baranowski about 3 years ago

Thank you Krzysztof. It's working on 2.5.0.

#138 Updated by Geetansh Jindal about 3 years ago

this patch is not working on our version , i am trying to patch redmine 2.5.1.stable

I getting the following outup

File to patch: app/models/issue.rb
patching file app/models/issue.rb
Hunk #1 FAILED at 94.
Hunk #2 succeeded at 134 (offset 13 lines).
Hunk #3 succeeded at 151 with fuzz 1 (offset 18 lines).
1 out of 3 hunks FAILED -- saving rejects to file app/models/issue.rb.rej

even we are not seeing any error message. but even after applying this patch, the purpose of the patch is not met. the purpose of this patch was : "Private Issues should be visible to Watchers". its not happening even after patch

Following are my environment details
Environment:
Redmine version 2.5.1.stable
Ruby version 1.9.3-p545 (2014-02-24) [i686-linux]
Rails version 3.2.17
Environment production
Database adapter MySQL

#140 Updated by Lucky Boy almost 3 years ago

Dmitry Salashnik wrote:

https://github.com/NEXSTEP/redmine_show_private_for_watcher

tested on last trunk

not help for me on 2.5.1

#141 Updated by Toshi MARUYAMA almost 3 years ago

  • Description updated (diff)

#142 Updated by Toshi MARUYAMA almost 3 years ago

  • Related to Feature #285: Tracker role-based permissioning added

#143 Updated by Go MAEDA about 2 years ago

  • Related to deleted (Defect #12116: Watchers added as a non-member doesn't receive emails notifications)

#144 Updated by Mustapha TAMI NOURINE about 2 years ago

Can anybody provide the same changes for redmine 3.0.1?

#145 Updated by Ling Li almost 2 years ago

In addition to the useful extended watcher plugin, is there a plan to implement the "Involve" mechanism?

#146 Updated by Michael Schaefer over 1 year ago

+1! we're so looking forward for this to become implemented. this really limits the overall functionality of issue tracking as it's implemented in our company. as we're on 3.x the patches don't really work for me. It would be really great to see this implemented!

#147 Updated by Jasur Mirkhamidov over 1 year ago

+1

mine is 3.1.0

is anybody tested?

#148 Updated by Roman Zak over 1 year ago

Please someone provide a patch for 3+ version!

#149 Updated by Pavel Konstantinov over 1 year ago

+1
It's the only thing that blocks me from upgrading to version on 3.x.
In my work-flow it's the key feature.

#150 Updated by Hang Xie over 1 year ago

patch for 3.1.x (working on 3.1.1 and 3.1.2 )

#151 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Feature #20106: Adding issue watchers to "Issues Visibility" permissions added

#152 Updated by Toshi MARUYAMA over 1 year ago

  • Related to Feature #16845: Add permission rule to allow watchers can edit issues added

#153 Updated by Go MAEDA over 1 year ago

  • Duplicated by Feature #13828: when users can only see their own issues; give watchers the ability to view issues they watch added

#154 Updated by Toshi MARUYAMA about 1 year ago

  • Related to deleted (Feature #20106: Adding issue watchers to "Issues Visibility" permissions)

#155 Updated by Jean-Philippe Lang 12 months ago

  • Related to Patch #14318: Watchers Alerted To Changes But Cannot See Issues (potentially) added

#156 Updated by Jean-Philippe Lang 12 months ago

  • Related to deleted (Patch #14318: Watchers Alerted To Changes But Cannot See Issues (potentially))

#157 Updated by Jean-Philippe Lang 12 months ago

  • Duplicated by Patch #14318: Watchers Alerted To Changes But Cannot See Issues (potentially) added

#158 Updated by Tobias Fischer 11 months ago

Hang Xie wrote:

patch for 3.1.x (working on 3.1.1 and 3.1.2 )

I can confirm that this patch also works for 3.2.3.stable.15464 and should be included as a feature in the next release.
This would be very useful!

#159 Updated by Go MAEDA 11 months ago

Tobias Fischer wrote:

Hang Xie wrote:

patch for 3.1.x (working on 3.1.1 and 3.1.2 )

I can confirm that this patch also works for 3.2.3.stable.15464 and should be included as a feature in the next release.

I want this feature, but I think any patches that uses watchers for access controlling purpose would not be accepted for now.

The following is Jean-Phillippe Lang's comment from #7412#note-13:

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.

See also #14318#note-23.

So we should think different approach.

#160 Updated by Tobias Fischer 11 months ago

Go MAEDA wrote:

So we should think different approach.

Okay, agreed. But Redmine really needs a solution for that!


Tobias Fischer wrote:

Hang Xie wrote:

patch for 3.1.x (working on 3.1.1 and 3.1.2 )

I can confirm that this patch also works for 3.2.3.stable.15464 and should be included as a feature in the next release.

While testing the patch private_issue_watchers_3.1.x.diff with Redmine 3.2.3 I found a bug which allows users to view tickets they are not assigned to or which they aren't watching.
So I wouldn't recommend using the patch in production!

#161 Updated by Tobias Fischer 11 months ago

For those of you who need the functionality right now, I suggest to use the patch allow_watchers_and_contributers_access_to_issues_3.2.0.patch by Fabrizio Sebastiani from #14318#note-22. It works well for 3.2.3.stable.15464.

However, I still agree with Go MAEDA that we need another/better solution for implementation in one of the next releases...

#162 Updated by kay rus 10 months ago

+1 for this feature

#163 Updated by Toshi MARUYAMA 10 months ago

  • Related to Defect #22977: A project member has no access and gets no notification, when being a watcher of the issue added

#164 Updated by Jan from Planio www.plan.io 9 months ago

  • Related to Patch #23546: Issue visibility "watched by, created by or assigned to" for roles added

#165 Updated by Jan from Planio www.plan.io 9 months ago

Go MAEDA wrote:

I want this feature, but I think any patches that uses watchers for access controlling purpose would not be accepted for now.

The following is Jean-Phillippe Lang's comment from #7412#note-13:

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.

So we should think different approach.

We've had similar requests to this at Planio numerous times and we've spent quite some time internally thinking about better or alternative ways. Yet we couldn't come up with anything simple that wouldn't make things even more confusing for users. Being able to set people as watchers AND being able to "involve" users via two different buttons seemed to be causing even more confusion unfortunately.

So, we've implemented this based on watchers for Planio and it seems that users "get it". We're not receiving many support requests by people who are confused by the new feature.

Felix has posted the patch in #23546 for everyone's consideration :-)

#166 Updated by Bruno Medeiros 2 months ago

Jan from Planio www.plan.io wrote:

So, we've implemented this based on watchers for Planio and it seems that users "get it". We're not receiving many support requests by people who are confused by the new feature.

Jan, I'm a happy Planio user and at the same time my company develop a custom solution based on Redmine. I see your point and I use this patch in quite a few Redmine instances. As a Redmine core developer, though, I wouldn't accept it on core, exactly as Jean-Philippe stated. I wonder if it is really a good idea to have it on Planio core.

The main problem with this patch, reported by a few of our custom solution's customers, is: Once you are involved in an issue (in this case, using the observe mechanism) you cannot stop receiving emails from that issue. If you stop observing, you lose access. If you keep observing, emails keep coming. If you reach that point, there is no way back. No solution. Period. And this is kind of obvious, because this patch uses something designed to handle email notifications to do access control, which is wrong by design.

Besides that, if you allow a role to add observers, this role is also allowed to give access to users that may not be supposed to have access. "Add watchers" permission becomes much more powerful and dubious.
See my previous comment for more details.

I think a lot of people demand that because they don't care about losing the observer mechanism, this is a valid way, but we need to accept one thing: Observe and be involved are different things, we cannot fully resolve the problem with only one flag. If you drop the observe feature and transform it in an involve feature (I think that is what most people that use this patch do), that's fine, but keep in mind that you may be creating a bigger problem for you if people want to use the observe as it was designed to work.

Also available in: Atom PDF