|
History
| Log In
|
|
|
|
[
Permlink
| « Hide
]
Jeff Turner [Atlassian] - 13/Dec/04 09:54 PM
Yes it would be useful. Thanks for the report. This is similar to having a Cc field (JRA-2167).
Further, it'd be nice to have issues created from email be able to assign watchers as well. The first cc address would become the assignee – all further addresses would become watchers.
Syd,
That is actually the case currently (first recognized Cc'ed user becomes the assignee). There will be a flag to disable this in 3.1 (see Jeff,
True – but what I was getting at is that the 2nd, 3rd, etc recognized addresses should become watchers. Sending an email to somebody via Cc is in my opinion very different from defining him as an assignee. Cc is in my experience used to keep people informed (=watcher), not to make them responsible for the task described in the message.
Using the first Cc email address to choose the assignee is therefore a special Jira convention (useful, but not intuitive for the enduser). It would be nice to be able to configure JIRA in a way that allows the evaluation of all Cc addresses as watchers. Certainly, making Cc'ed users become watchers seems more logical than making the first an assignee.
But anyway, the main issue is how to add watchers from the web interface. Here's an idea... I put this comment into JRA-5959:
If this is ever implemented, one of the choices could be "All Watchers". This would send an e-mail to all watchers without having to perform an operation to cause an email to be generated nor have any reliance on the notification scheme being set up to send an email to all watchers. While it would be preferable to add watchers before the issue is created (and the emails generated), that is a signficant change to the user flow/interface. By implementing JRA-5959 in that manner, one could add an issue, then add watchers, then click "Email this issue (to all watchers)." This would be a great feature for us. Our helpdesk is going to start using JIRA to communicate with the developers. We would like to be able to have them create and issue, with their username as the reporter and the callers username as a watcher. Even better would be the ability for them to simply add the callers email address as a watcher so they do not have to have a JIRA account.
Once we modify the add watcher field to a System Field, you will be able to add this to any of the configurable screens. I think we are planning on changing this soon.
Cheers, Can we also have an addWatcher() method added to the RPC (SOAP) Issue Service?
We have some custom servlets which use the SOAP interface to create Jira issues. This holds many advantages for us. However, even with the flexability of "Component Leads" and "Project Leads" I find that Jira's built-in rules for assigning and routing tickets doesn't fully meet our needs. So I have a lot of "if/then" logic in our servlets to assign tickets to the right person. The use case I'm working on right now is: If an Issue has a priority > X then make my supervisor a watcher on the issue. Unfortunatly there isn't a 'setWatcher()' remote method available that I've found. Should I make this a new request or leave it as a comment to this issue? A search of the frequent issues yielded way to many results for a search for "watcher rpc". I don't have the Jira source code but I did download the RPC plugin and the Dev Kit, but it appears that I need to have the source code of the entire product in order to implement the method (please let me know if i'm mistaken!!) Thanks! Elliot looks like no activity on this for a while - I hope this feature can be added soon. I think it's very useful for a watcher to know immediately when a new issue is filed where they are a watcher.
You may not be able to add them as a watcher at issue creation, but you can so it another way, quite easily. Create a custom field of type "Multi User Picker" (e.g. "cc to"), and add it to the edit screens of your field configurations. Then add that group to notification schemes where watchers are. In my opinion, it's easier to use than watchers - the only difference being that there's no security to manage who can add/remove this type of watcher.
I have added a commento to JRA-9910 but in fact I have asked what requested in this issue. I have suggected the following :
(...) Could it be possible to have a new "Custom Field" that I can associate to a Screen used to "create" an issue, in which who creates the issue selects the watchers receiving also the first notification , when a new issue is created? Creating a new Custom Field type and associating it to Screen would solve the issue reported by Bernard and probably extend also the concept. Antonio Right, Antonio. That's exactly what I've done. The only drawback is that there is no permission on who can access the custom field, until
hi folks, after having nicely downloaded and use the last JIRA version, which I do like, 3.3 I suggest the following then : since you have introduced the concept of "roles" (which I like as in this way my permission profiles will be all identical, based on roles, and I will set roles per Project), why you dont add a "system role" , called "default watchers" ??? In this way one, per Project, can define a number of default watchers that are added each time a new issue is created.
Extending this concept, if you also create a new system "field" named "watchers list", one can add it to the Screen of the issue and allow the Reporter to modify the default watchers list, while creating it. Ops...sorry. As "last JIRA version" I meant : Enterprise Edition, Version: 3.7.3-#187.
> why you dont add a "system role" , called "default watchers" ??? In this way one, per Project
You can create a "Default Watchers" role, with default users. Then configure your notification schemes to notify this role's members. Thanks Jeff
but If I do like that, how about "private" issues? will they be notified also to users not part of the "private" Issue Security Level ? I mean, is your suggestion compatible with the fact I want to keep "issues" private to given users? You feedback can be : why you want some users to be always notified if they are part only of a "public" group? A. > but If I do like that, how about "private" issues? will they be notified also to users not part of the "private" Issue Security Level ?
> > I mean, is your suggestion compatible with the fact I want to keep "issues" private to given users? As a rule, JIRA will not email users any information they cannot see through the web interface. Even if someone is listed to get an email in the notification scheme, if they do not have permissions to see an issue (due to its security level), they will not be emailed any updates on it. superb! this is an affordable workaround until JIRA goves the chance to add "watchers" (in the JIRA full meaning) as a Custom Field to be aded to any Scheme used while opening an issue.
To take full advantage of this suggestion you gave me , i'll post a request for improvement, asking for a Custom Filed able top display the list of users selected for a Role, such that I can show in the "issue view" the "Default Watchers" I have just created. Once again, thanks for the support A. There seems to be a solution to this here: http://confluence.atlassian.com/display/JIRACOM/Watcher+Enhancements
Like many others, we also have added a cc custom field with a mutliuserpicker and then a custom notification scheme, but I would like to see it work like it is on the confluence page. Please add this to a next JIRA version, the code is already written. What Wim stated looks reasonable. Are you considering to add (code available so almost 0 cost) this to next JIRA version?
I just saw a "change of state", few minute ago (ehm...I was observing it  ) from Chris. Is this a good sign ? There are 2 events when you want watchers to be informed about an issue, when an issue is created or when a watcher is added to an issue. Actually, when you inform the user when he is added to the watchlist, there is no need anymore to inform him on issue creation (this issue).
|
||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
 |
|
Improvement
Open
Major
Ability to add watchers during issue creation
