nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

How to make it so that the sender of the request could see who the performer is?

morty -

Как сделать так, чтобы отправитель запроса мог видеть, кто исполнитель

Accepted answers

All comments

Patrik Korovsky

Hi @morty -

This is currently not possible. The "assignee" field is hidden by default and cannot be shown.

This feature was requested here, you can vote for it:
- https://jira.atlassian.com/browse/JSDSERVER-328
- https://jira.atlassian.com/browse/JSDCLOUD-328

You can create a custom field, mark it as "performer" and display it to the customer in the Help Desk. You can do this in the Project settings -> Request types -> Request form.

Will this " performer" also be the "assignee"? If so, you can create an automation that will populate the custom field with their [~accountid:XXX]. Which would show in the Service Desk as so:

Since I'm not sure how you would like to use it, please let me know if this is enough information for you.

Cheers,
Patrik

Kate Pawlak _Appsvio_

Hi @morty - ,

Using native functionalities, it's impossible to present the request's Assignee. You can display Assignee on the Request page as an additional column.

You can also vote for the feature request which Patrik listed in the comment. But looking for other requests we can wait and wait without any resolution for years...

If you want to show it on the request, you have to use the app. Our Feature Bundle for Jira Service Management provides this feature, and many many more, such as a request edition, panel with workflow steps, or highly customizable announcement banners.

Best regards,

Kate from Appsvio

Patrik Korovsky

Hi @Kate Pawlak _Appsvio_

I have to disagree with the statement "Using native functionalities, it's impossible to present the request's Assignee". My solution is a workaround, but it shows the assignee and automation can keep the assignee actual, so technically it's possible using native functions.

Kate Pawlak _Appsvio_

But as I understand you have to add a custom field where this value will be added from the Assignee field. To show it on the request, you have to add it to the request form, so it makes your customers confused and think that they have to fill this field. So, what is technically possible doesn't always have the correct business use.

Patrik Korovsky

Thank you for your opinion and I understand that the sale of your product influences it. However, I am not trying to sell a product; instead, I focus on helping people. I don't label one's business use case as right or wrong; I leave that up to them.

If we don't prepare for this in advance, we can confuse our customers. However, we can avoid this if it is acceptable for us to have a pre-populated field:

Automation to add assignee tag
Result

There are many ways to approach this. I am simply listing them as possibilities.

Another is to create an automation that will add a form which updates according to the assignee. This way, the customer will not be "confused" as long as we explain our workaround:

Form set up
- Create a new form with your custom field linked (Mine named "Customer Care ID")
Automation
Result
- The created form when opened will show the current assignee

Of course, we can also create another automation to update the custom field every time the assignee is changed:

When: issue assigned
Then: Edit issue fields
- Your custom field with smart value: [~accountid:{{issue.assignee.accountId}}]

All that being said the app Feature Bundle for Jira Service Management seems to be a good solution with other great features. I'd say it's fairly priced, if you don't want to be dependent on workarounds, give it a try.