kewilliams It's really sad to see that you prioritize security-related features by popularity, only. Don't you have any security-aware people (like CSSLP) involved in your products development?

Thanks for taking the time to raise this issue.

Due to the large volume of JIRA feature suggestions, we have to prioritise our development efforts. In part, that means concentrating on those issues that resonate the most with our users.

I am writing this note to advise you, that we have decided to close your Suggestion as it has not gained traction on jira.atlassian.com. We believe being upfront and direct with you will assist you in your decision making rather than believing Atlassian will eventually address this issue.

Thank you again for your suggestion and if you have any concerns or question, please don’t hesitate to email me.

Kind Regards,
Kerrod Williams
JIRA Product Management
kerrod.williams at atlassian dot com

More generally, adding or removing a watcher should trigger a proper event, which could be caught and handled by an appropriate listener. It seems that the entire Watcher mechanism needs to be rebuilt so that the watchers field is more like a regular field. This would allow resolutions to many watcher-related issues.

This is necessary for proper auditing.

In addition, the suggested workaround is no workaround at all - it's just saying "Don't use that mechanism".

You're absolutely correct in that it is not a viable option for you.

I actually like the fact that watchers can be controlled by security and cc field can't. Even when issue security is in place, you couldn't use it since anyone who could edit the cc field could add/delete themselves as well as anyone else. Which is the part I like

Hi Neal,

after some testing I've come to the conclusion that this workaround is no solution in our case or at least needs a bit more effort.

Pro:

• change history is fine
• ability to set "watchers" = CC users during the creation of the issue
• security settings are picked up in the same way as they are for watchers

Con:

• need for data migration for all existing watcher entries to CC user entries
• no way to restrict the access permissions independently of other issue fields

Unfortunately, the last point is prohibitive. Although most users don't use the web interface, those who do routinely add and remove watchers on our issues (they are the key users who know best which person can resolve questions on their end etc.). It is a must that this ability is preserved, at the same time I cannot grant them the premission to edit issues.
Perhaps a plugin that restricts editing to this field only could be written, but I suspect that would be rather messy with the current permission structure.

Your suggestion will work fine as soon as field based security is in place.

Kind regards
Axel

Thanks Axel, though as Neal said - the CC field is a good option.

Axel,

If instead of "watchers", you use a custom cc field (which accomplishes the same thing for you), then you can see, through the change history, who the "watchers" (members of cc group) were at any point in the life of the issue. To see what I mean, take a look at issues JRA-5493 and JRA-2167.

Since your customers won't be using the web interface anyway, just instruct your developers to include the customers in the CC list and adjust the notification scheme to notify members of cc list. I attach a sample for you to show what I mean.

Also, "User Management" isn't the best component for this issue.