In the Atlassian Service Desk FAQ about including colleagues in a ticket it says:
If you would like us to make your ticket visible to colleagues on your team, just comment on the ticket with their names and email addresses and we'll take care of the rest, including creating accounts for your colleagues if they don't already have them.
Can someone shed some light on how this is being done? Do the watchers have the "normal" JIRA view of the ticket or does everyone access it through the Service Desk?
We recently rolled out Service Desk for our IT department internally and this feature has come up. My initial thought was to create a "Power User" role with "Browse Project" permissions to be able to be added as watchers to tickets, but that would grant them access to all tickets. So I'm interested to know how Atlassian (or others) are dealing with this.
@Dave Gunn, hopefully my comment was not taken as a reprimand. It was meant as a comment to say that if you are interested in having JSD-269 implemented then the best place to share your voice is in the ticket itself vs. the Community since, for the most part the Community is monitored by other customers like yourself and me. Often Community members are not aware. My appologize to all if I offended. :-(
Thanks, Jack. I'm a little confused here as @Bruce Hays has replied to my portal request helpfully suggesting (amongst other things) asking the community the question. But you're saying I should comment in that ticket and not ask the community. What I really need is a simple answer to what seems like a simple question. Our servicedesk went live yesterday and having watchers is a vital tool but I get 'permission denied' messages. I've tried the answers in the JIRA communities and two different add-ons but still getting no where. I've tried changing permission levels as much as possible. A step by step tutorial would be great. Anyone out there who does have the answer?
I'm tied up for the moment but will take a run at providing an answer in a bit if someone else in the Community has not already done so by the time i get back.
In the meantime as @Michael Moynihan mentions here the ticket mentioned has been fixed and is available. Whether that addresses everyone's question/needs begin raised here I we will need to assess. In the meantime here is something to read that "may" help some here.
back in a bit...
@Dave Gunn, regarding the 'permission denied' messages you are receiving, can you elaborate? where are you seeing these messages and during what action? Ultimately I suggest that if the details I provided in this thread do not address your question(s), you should create a new thread as i just noticed this thread started back 2014 (I didn't notice that originally) and very likely the issues you are experiencing are unrelated I suspect.
Forgive me if I am wrong, but the ticket is closed and the last post in the ticket explains this has been done.
I checked it on the cloud version which my company is using, and sure enough, I can add watchers (other than myself). This is done via the (...) menu on the top right of the ticket.
All, I'm back from my meeting and wanted to weigh back in here. Bear with me if I get sideways on this as it is a bit difficult to follow the thread. Let's rewind to the beginning with @Scott Searcy1's initial questions:
Q: "Can someone shed some light on how this is being done? Do the watchers have the "normal" JIRA view of the ticket or does everyone access it through the Service Desk?"
A: This depends on the classification of the user and what software applications you actually have, e.g. just JSD or JSD + JSW. Let's take the most likely case first. You have JSD agents and JSD Customers. As a customer, you can add a participant via the portal, or email (if configured). As an agent or admin you can add via portal, email or the application itself. Typically, as an agent/admin you are going to be working in the application but you have access to all methods. This is well documented in the link I provided earlier - Adding Request Participants. An important note is specified in the documentation right up front - Request participants are customers and organizations who can view, comment, and receive notifications about the request. Participants receive the same notifications as the reporter, and can turn off notifications at any time.
Q: What are watchers?
A: Fair question and I will admit this can be confusing when "Participants" is thrown into the fold. There are some subtle (?) differences and in the previous documentation there is a section that might explain this...
You can also involve other agents or JIRA users to get help with an issue. For example, you might want JIRA Software developers to help analyze a bug that a customer has reported. To involve internal users, add them as watchers. As watchers, they're notified about internal activity on an issue, and can communicate with you via internal comments.
So the main take away is the notified about internal activity verbage. Watchers get it all Participants get the 'customer' view, i.e. what is consider public. Finishing up my response (sorry for novel) here are some other tidbits that I thought might be helpful based upon reading this thread:
Bottom-line take away on the notifications: Use Participants for Customers and Watchers for those with access to the application.
I hope this has helped folks here and again I apologize if my earlier response came across poorly. As a community contributor, I want to be helpful but as it is a sideline activity at times my responses are not well formed. :-)
Hello Community 👋, I'm a product manager at Atlassian, looking at improving change management capabilities across our products. In particular, we're looking at bridging the gap between Dev & ...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events