Our IT department is using Jira Cloud with Jira Software and Jira Service Desk.
Our Service Desk issues have a field called "Request Participants". Our Software issues do not have this field available. I've added it, but it has no value in Jira Software projects and is not visible in the issues.
How can I add this field in a Jira Software project with Jira Cloud?
It is not possible to use that specific field outside of a Service Desk project.
Instead of that field, you can instead use the Watchers field. It provides the same feature as Request Participants. The difference is that JIRA Service Desk needs Request Participants option in order to allow JSD Customers (that do not have access to the main JIRA site, only the customer portal) to view another customer's issue. But for a non JSD project all users are JIRA users that can login to the main site. The watcher field is where they can add users to view the ticket, and continue to get notitications of changes to that issue.
Watching and voiting for issues has some more info on using the watchers field.
Does this help? Or are you looking to allow service desk customers a view into an issue on a non-service desk project?
We have a situation where issues could be moved from the JIRA Service Desk to a non-JSD project based on the work that is required. We'd like for any request participants who have been kept abreast of the progress on the JSD issue to also be aware of the progress made on the non-JSD issue. Based on what you've said, the functionality does not exist today to continue this communication with the request participants if the issue has been moved, correct?
Thanks for your feedback and time!
That's correct, Kimberly. The request participants field is unique to Service Desk projects. This field can contain users in the Service Desk customer role that are not able to get the typical Jira Core/Jira Software notifications because these users are unlicensed Jira users. Because of this, in order for these users to get updates, it has to be via Service Desk and that only works if this issue remains in a service desk project.
In cases like that, I would recommend actually cloning the issue and then moving the clone to the new project for other work to be done. This way there exists an issue link created between the two. This isn't ideal though, because obviously changes to this clone issue in the new project still are not going to notify the report/request participants on the JSD ticket, but JSD Agents could use this kind of issue link to then keep track of both issues and update the customer with details on what is happening with other issue.
Alternative to that, the only other way that these users would be able to see this issue could be if they had browse permission on the project. That would likely mean you would have to open that project publicly to the 'anyone' group. This might be a solution to allow those users to continue to watch this other issue for updates, but if you do that, you just need to be aware that setting a project permission to allow browse to the anyone group gives even anonymous users access to view all the issues in that project.
Alternatively, if the folks in the previous JSD project exist within your JSW, and you just want to keep the requested participant value(if you are using this field for gadget filters), you can simply create a custom field called requested participant as well with multi-user picker custom field type.
And if you want these folks to be added as watcher automatically, you may use JIRA Workflow Toolbox to add a workflow post function to do that. Where it will pick up the value from the multi user picker field and add everyone from there into the watcher
@Andy Heinzer Actually when you clone a JSD ticket into another project, it keeps the request participants ON the new ticket. They receive emails/notifications but you have no way of removing them.
Please help bc I have people receiving emails who do NOT want to receive emails
My suggestion to clone the issue and then move that clone to another project was specifically intended to move it to a Jira Software type project. Certainly if you moved it to another Jira Service Desk (now called Jira Service Management, JSM) project, then yes, that field will be maintained there.
But the suggestion I made was meant to keep in mind that requested participants is currently only something that JSM projects can use.
If you have another team that uses Jira Software, then this suggestion would be useful for them to potentially track some work related to this linked issue. The requested participant feature is designed specifically for including individuals into JSM requests, which tend to have far more restrictions about who can see them.
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