We're trying to use the Service Desk application to allow the public to create new bug tickets for our game. However we would like to allow them to view tickets that have already been created. How do we allow customers to view other tickets in the project?
This simply cannot be dismissed with a simple statement when so many people see it is a HUGE blocker to the way their customers would like to use the product, as is demonstrated here: https://jira.atlassian.com/browse/JSD-270
Customers can view other customers tickets by adding them as a participant, as per the recent dpeloyment details found here - https://confluence.atlassian.com/display/Cloud/2015/01/16/Upcoming+Atlassian+Cloud+Upgrade+for+week+starting+18+January+2015
JSD-270 really needs to be addressed as soon as possible as it will win a lot of new custom, and keep the rest of us happy!
There needs to be a way for Service Desk users to see the status of their tickets as these tickets move through the development projects. The way we have to set it up now, is to link the service desk tickets to a copy of said ticket in one of the various projects. There should only be one instance of the ticket, and the customers who submitted it should be able to track its progress, no matter where it goes. Period.
Just following up on this for people arriving here from Googling. JSD-270 has been addressed (thanks for linking it Tolu!) and you can configure your service desk to let anyone in an organization (see documentation about organizations) see issues opened by other people in the organization.
I agree that it's a bummer that it wasn't addressed sooner and am sorry to see some people having a difficult time because of it. I know at my company we had to jump through some hoops to address people's concern about loss of transparency internally while waiting for the feature to be built it. Luckily though it works pretty well now, so folks just setting up Service Desk are good to go.
Hello Daniel, I have searched and searched and am unable to find the ability to "see issues opened by other people in the organization" that you spoke about... I followed the documentation you provided, and simply couldn't find it... This is a HUGE thing that we really want to implement, so if you could point where you found that, please let me know!
I appreciate the response. I left out a crucial detail. We'd like one customer to be able to see all of her organizations tickets in her portal by DEFAULT... otherwise, it's up to the requesting agent to "share" their ticket. We don't want them to have that choice. We would like all issues raised by anyone in her organizations (she's in multiple organizations) to be "shared" with her automatically.
Thanks again for your time!
I also was wondering if Matthew got a resolution to being able to allow individuals or groups of individuals to have the ability to search for issues in their organization by default.
I was thinking this could be a work around to the much larger issue of if I raise a request on behalf of person X, person X does not see this under my requests.
We have end users who stop by individual IT offices, our service desk, call or email in for help. We need to be able to create issues on behalf of people and allow those people to go back and find those issues at a later date to either interact with those, or just go back to see the "how" something was resolved.
Is it possible to let customers see all tickets from customers in other organizations within the project, and not just their own?
We currently have a client who performs UAT but also has a third party agency do some UAT on their behalf. Different organizations, but they need to be able to see each other's tickets as well as change the status of all tickets within the project.
Scott, sorry to say but my earlier proposed workaround is not an option as all internal comments are visible to customers when they get access to the JIRA view of the issue. The only workaround would be to track these public issues in another - non service desk related - project.
Best of luck! JIRA has the potential to be amazing, and it greatly saddens me that they aren't yet. I can only hope they read these forums, and, if you end up wanting to re-visit the idea of adopting Jira in the future, that they will have made their service more usable by the time you decide to adopt their platform.
Hi Nicolas & Matthew,
We're sorry to hear that you're frustrated with Service Desk, however, we'd like to assure that Atlassian is always willing to help teams get their work done.
That said if you're looking for a way to grant access to a manager, the best way to do it would be by using Organizations. However, this would also cause the issues to be viewed by everyone else in that same organization.
To create an organization, you can just go the Customers section of your Service Desk > Add Organization. After that, you can add the manager & their respective users in that organization and then start adding that Org. to the tickets that you wish for that manager to see. When users inside that organization are raising tickets they will have the option to either share or not the issue with that organization.
Other than that, you can add this manager as request participant on all issues, and you can automate this for new issues by using a third-party add-on such as Automation for JIRA.
At the time this thread was created, Service Desk did not have Organizations. These organizations allow you to better group your customers and in turn let those customers share their requests with other users in their same organization. Both Cloud and Server versions of Service Desk have this feature now, and have for some time.
However all the customers within an organization are treated equally. Sharing an issue with an organization gives all the members of that org access to that request. Service Desk does not have a role such a 'customer project manager', one individual that would be a customer role user, but have views into other customers issues.
It sounds like this is a role that you are both looking for out of the product. There is an existing feature request for this over in https://jira.atlassian.com/browse/JSDSERVER-4302 - server and https://jira.atlassian.com/browse/JSDCLOUD-4302 - cloud. I would recommend voting on that specific feature is this is something more specifically you want to see in the product itself.
Thank you for the reply, Rodrigo. My main point of contention has been that "customers" who submit a ticket to the Service Desk are unable to track their tickets once they have been moved from the Service Desk to other project that our Jira agents are working on. The "workaround" that has been suggested by Atlassian has been to keep the tickets open in the Service Desk, and link them to identical tickets in other projects, but this is nonsensical, in that we want only ONE instance of a ticket, and, no matter where it goes in the various <non-servicedesk> projects we have, the Issue Reporter should continue to ne able to view its status. We are not asking for Service Desk Customer CONTROL of said issue, but that the Service Desk Customer has VISIBILITY of their tickets, no matter where they go in the non-service-desk realm.
Hmmm, I see. This is indeed not possible (currently) without granting a Software/Core license to your customers (besides changing your permission scheme, issue-level security and so on), however, a workaround scenario that I can think to this is by using JIRA JMWE.
You could create a transition in your workflow that would automatically create a linked issue in another project. Then, also by using JMWE you can copy the comments from that linked issue to the original issue. This would keep the client on the loop without much customisation in your environment.
Thank you, Rodrigo. I appreciate you being responsive to this. I will remove my initial suggestion for migration away from Jira, but, I (as well as many other admins), are generally upset that tickets can't be tracked by original reporters throughout Jira. The way it is now, a reporter submits a ticket that is for a "feature request", and once we move the ticket to the appropriate project, the submitters can no longer see the ticket, which is, frankly, absurd.
@Matthew Learoyd you can always link that JSD ticket to other linked issues inside Jira projects. I have with automation for jira (codebarrel) rues that create linked issues, replicate "internal" comments, priorities, assign as watchers or assignees from original ticket even to JSD transition to certain status based on internal linked issues transition statuses (with or without conditions).
You should give it a try and I am happy to help.
@Matthew Gaffney try using automation for Jira to automatically create linked issues and transition your JSD ticket based on linked statuses avoiding your customers to access internal tickets. I do it that way given we support several clients with several customers within those organizations and our internal dev/ops team give level 2 support when coding and releases needs to be ejecuted.
Another workaround is that you give "browse project" permissions to your internal team can work on that JSD ticket.
Hello there Cloud Community members! Today, we’re thrilled to announce Jira Service Management, the next generation of Jira Service Desk. Jira Service Management touts advancements in IT service ...
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