[#JRA-13760] Adding or removing a user to/from the Watchers list of an issue should cause a change history entry

JIRA

Adding or removing a user to/from the Watchers list of an issue should cause a change history entry

Created: 16/Oct/07 10:08 AM Updated: 29/Nov/07 06:56 PM

Component/s:

Issue Fields

Affects Version/s:

None

Fix Version/s:

None

Time Tracking:

Not Specified

File Attachments:

None

Image Attachments:

1. screenshot-1.jpg
(16 kb)

Environment:

Enterprise 3.11 WAR / Tomcat 6.0.14

Issue Links:

Reference

This issue relates to:

JRA-5494 Adding a user to a watchers list should cause an email notification

Participants:	Axel Faustmann, Josh Goodall, Neal Applebaum and Nick Menere [Atlassian]
Since last comment:	33 weeks, 2 days ago
Labels:

Description

« Hide

Among other things, we are using JIRA for the tracking of support requests. Issues are created via email, notfications are sent out to the reporter and all watchers (usually at the customer end) whenever a new comment is made. Reporter and Watcher contribute to the issue by replying to those notifications. The JIRA Web Interface is not used by most users on the customer side.

In this setting, it is of interest to know which notifications an individual user actually got. In the change history, all relevant information is available - but not when a user was added or removed from the watcher list.

All

Comments

Work Log

Change History

Sort Order:

Ascending order - Click to sort in descending order

[ Permlink | « Hide ]

Neal Applebaum - 16/Oct/07 02:11 PM - edited

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.

[ Permlink | « Hide ]

Nick Menere [Atlassian] - 16/Oct/07 09:30 PM

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

[ Permlink | « Hide ]

Axel Faustmann - 19/Oct/07 08:22 AM

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

[ Permlink | « Hide ]

Neal Applebaum - 19/Oct/07 12:02 PM

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

[ Permlink | « Hide ]

Josh Goodall - 29/Nov/07 06:56 PM

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".