For some reason my customers are unable to see the description of their issues in the customer portal, I have checked to ensure the field is set as visible, which it is, but they still are unable to see it.
Alright, finally resolved the issue.
Thanks everyone who helped.
I had a post function assigning the request type "Emailed Request" to all tickets created, but this was assigning the request type from another Project. Causing it to seem fine, but glitch out and not show the description.
The reason I made this, was because when cloning issues it removes the request type, and the automation in jira doesnt have the ability to assign a request type.
The way I resolved this issue was by finding the Legacy Automation tab! For some reason this has the ability to edit the request type, but the normal automation doesnt.
This isnt ideal as it doesnt seem to have a global automation function, so i had to create an automation for every project (which is alot) to assign the request type desired when the request type was empty like in this tutorial:
Hi @Bailey Davis,
Thank you for sharing the resolution.
I'm glad that we could help and that you were able to fix the issue.
The Automation (former Automation for Jira) still doesn't have the option to edit request type, only the Legacy Automation.
There is a feature request suggesting this improvement:
Hello @Bailey Davis,
Thank you for reaching out to Atlassian Community!
When the description is not visible in the customer portal, the most common issue is that the Request type is empty.
This happens, for example, if the customer creates the ticket in the portal but then the ticket is moved to another project or the issue type is changed, the request type will be empty because it’s not possible to set a new request type when moving the ticket.
Please, go to the affected ticket on the agent view and check if the Request type is not empty.
Thank you for the details, Bailey.
I checked similar cases and all of them are the request type or the description field not added to the request type.
What Joseph mentioned is also important to check. On the request form, it’s possible to add a display name for the fields, so it will show different names in the portal and in the agent view.
Can you please click on “Body” to confirm if it’s the Description field?
Also, can you share with us a full screenshot of the ticket in the portal and the very same ticket in the agent view? (Just make sure to hide private details, like the site URL and full name of the customers/users).
How was the ticket created (portal, email, or using the create button in Jira)?
Is it happening if creating using a different method? For example, if you create using the Create button in Jira and select a Request type, does the same issue happens?
I suffer from a similar Issue. All fields in the "Details" section are not displayed on the Portal when the "Customer Request Type" has no group, eg its in "Hidden from Portal".
If I assign it to a group - all fields appear under details in the Portal.
Have made a Support Ticket at Atlassian
The 2nd post function call seems to be odd where it set the REQUEST TYPE. I am not aware of any thing out of the box WF will set the REQUEST TYPE. Was this post function call a custom one for your env?
Don't know if you can remove the 2nd post function call and republish the WF. Afterward test out by creating issues via the portal.
In addition, can you check the REQUEST TYPE of gi/email form setup. Lastly, do all of your REQUEST TYPE uses the same issue type that associated with the same WF? if not, you may want to create a new REQUEST TYPE based on a different issue type + a copy of the WF without the 2nd post function call, then conduct your testing further.
Hope this helps.
I needed that post function so that it automatically assigns all jobs created to "Emailed Request" since there is no way to do that in automation.
Although I have now realised that is likely the issue, as the "gi/email" is the email request type for a different project then tickets are in.
Our workflow is as follows:
Customers email a request to one generic email address, automation decides what organisation they are from, then clones the ticket to the correct project, and resolves the current ticket in the incoming project.
It is then meant to be assigned to "emailed request" as when being cloned it loses its request type.
Do you know any way I can fix this to work without creating a workflow and post function for each organisation (currently all the projects share the same workflow as its easier to manage since there is alot of projects)
In your original project where the original issue is created, you can create cloned issues in other projects via post function in the WF or use Automation for Jira (it should be a part of JSM license) to create the cloned issues.
If that is possible, you only need to have one unique WF (without the 2nd post function call) to apply against the original project.
Don't know if it helps or not. It is an idea for you.
Yes, I am currently cloning the issue via automations, but when cloned it clears the request type field, which I need set otherwise the issue doesn't show in the customer portal.
Hence why I had the post function to set the request field type to gi/email
Although I have realised this is my issue as gi/email is the request type for our "general incoming" project, so once they move over to a different project, that breaks and hides the description from the portal.
Is there any way I can set the request type to "emailed request" automatically when cloning issues to different projects?
Or any syntax I can use in place to "gi" in the "gi/email" post function that will auto fill the correct details?
Your current situation is very interesting. Can you create a new request type and just expose the summary and description fields from scratch? Afterward, try to create issue in your JSM project from the Portal UI.
Hopefully, the new issue's display will be correct. At this time, for your existing Request Types, can you also remove the Body field and save the edit. Then, re-add the Description field back to the Request Type to conduct re-testing again.
Lastly, have you try to create an issue via other browser apps to determine if it behaves the same way?
Hope this helps.
Can you go to your JSM project and access project's field configuration scheme and see if there are duplicate fields named as "Description". I believe you also confirm that if you access the issue directly in the project (not from the portal, the Description field content is there right?
What you encountered is something that I have not seen before.
Hi @Bailey Davis,
Can you please check the history tab of the ticket to check if there are no changes after the ticket is created?
Also, check the Post Functions on the workflow (Project settings > Workflows > Click on to edit the workflow > Select the Diagram mode and click on the Create issue transition > Post functions).
Then, please confirm if there are no post functions related to the description and request types.
So, I found that when creating a ticket (no matter how it is created) or the request type, the description isnt shown in the portal.
If I manually go in and change the request type after the fact, the description will then show in the portal. Even if i change it back to the initial request type.
Any ideas why this may be happening, and how I might be able to get around this?
If the portal, customer should see the "Description" field (the field they entered) at the bottom of his/her issues under the Activity section (See example below). When an issue is created, the content should be listed under the "Details" area.
You should also check to ensure that your "Body" field is mapped correctly to the "Description" field in your Request form.
Please let me know if it is properly mapped.
Best, Joseph Chung Yin
Jira/JSM Functional Lead, Global Infrastructure Applications Team
Take a look at what Atlassian Team reply in this ask. Also did you confirm that your BODY field for the request form is mapped to the actual Description field in your JSM project?
@Katarzyna Pawlak _Deviniti_ - I know that my image screenshot is from the server version. In most cases, the server display is similar/common to the cloud display. Thanks for pointing that out.
Hi Everyone, In this tutorial, we will show you how you can monitor an SLA, and send notifications before or after the SLA has been breached. SLA Threshold Trigger The SLA t...
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