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; } } }

Issue created by automation doesn't show issue details in portal view

Koloman Pfeffer

Hi everyone,

I just hit a roadblock trying to set up an automation that creates a JSM issue. Maybe I'm overlooking something here, maybe someone here has an idea, how this could work.

My use case/desired process:

Users should be able to trigger the creation of an issue via an Automation on a Confluence page.
The issue's portal link should be posted as a page comment.
The user should then switch to the page and fill out some additional issue fields.

Step 1 and 2 work fine so far, but when I change to the customer portal, the issue is completely empty and none of the issue details are visible. If I create the same request type manually over the portal, the looks completely normal and all fields and details are visible.

I already tried playing around with the create screen, but to no avail. Is there any setting or permission I missed, which could enable this?

Additional info: In Confluence Automation I can't set a Request type, so I set the RT after issue creation via another Automation in Jira.

Thanks in advance!

Accepted answers

All comments

Tomislav Tobijas

Hi @Koloman Pfeffer ,

Interesting problem... So, link redirects users to portal-view of the raised ticket and not the Jira view?

If you look at the Jira view of this item, are field values visible there or do they also appear as empty?

Btw, can't you use "Additional fields" within Create work item in Jira action to fill out Req. type immediately?

Cheers,
Tobi

Koloman Pfeffer

Hi @Tomislav Tobijas

Yes exactly - this automation should be triggered by users who mostly don't work in JSM, so they don't have a licence, but they should be able to interact with the ticket in the portal view.

In the Jira/issue view the fields look completely normal and all values are where they should be. There is no difference visible, but to me it seems that the portal view differentiates if an issue was created via the portal or not.

In this case the create work item action was triggered within Confluence Automation, where you can't set a request type, because it's an unsupported field. Just to be sure, I set up another automation in JSM that creates an issue and fills out the RT immediately, but it again appears empty on the portal view.

Thanks for your input!!

Alexander Hohmann

Could it be a branch issue? Branches run concurrently, not sequentially, and therefore a branch cannot tak for granted that another branch has completed.

Koloman Pfeffer

@Alexander Hohmann Thanks for your answer!

I don't think it's a branching issue, since all rules run successfully and all actions are executed correctly. I this case it is (from a user perspective) an issue of displaying the issue data on the portal view.

Marc -Devoteam-

Hi @Koloman Pfeffer

Who is the actor of the rule in Confluence, does this user have a JSM license?

Connection from Confluence automation to another product is based on the user who has made the rule and the connection from Confluence to Jira in the rule.

I can choose the Field Request Type.

Can you show:

1. images that show your complete rule.

2. images showing the details of any relevant actions/conditions/branches.

3. images showing the Audit Log details for the rule execution.

Koloman Pfeffer

Hi @Marc -Devoteam-

The rule actor in Confluence is myself, so there is a JSM license.

I don't think this is inherently an automation issue, but a displaying issue in JSM. I already tried another way of creating the ticket (Web request in Confluence Automation > Web hook in Jira Automation > create work item with request type), but the ticket still didn't show any data on the customer portal view.

Can you show how you could change the field "request type" in Confluence Automation? I can't seem to access it in the action that creates the ticket.

Here you have pictures of the first rule in Confluence Automation as well as the second one with the web request. Audit log is inconspicuous, the rules themselves run as expected and without errors. Rule 3.png Rule 2.png Rule 1.png

I also added pictures from the portal view what it should look like (this works when I create the ticket manually) and what it does actually look like when created via automation. Sorry, I had to redact a few fields, but it should still be clearly visible, that there is a big difference.

Portal 1.png Portal 2.png

Marc -Devoteam-

Hi @Koloman Pfeffer

So you are the reporter, are you also listed as a customer on the portal?

Darn, I see someone created a CF Request Type in our instance, that threw me of course.

I have tried it as well.

If you don't set a Request Type afterwards, I don't even see it in a queue.

I don't see any fields as I only set description field, but that field is not used in the request type I set.

If I change the request type to a request that uses the description field, I see this information on the issue in the portal.

So it might be related to the fields you set in the automation in Confluence and if these fields are available on the request type on the portal.

Niote, it doesn't work if you use a form where the form field is linked to a Jira field used.

Tomislav Tobijas

Hi @Koloman Pfeffer ,

I've just seen you reply in other thread. I've tested this with Description field, and it displays all info in the portal view once the request type is set (same as Marc confirmed).

Can you share which field types you are using?
For example, which field types are "Confluence Link", "Confluence Page ID" and everything else that is not showing?
Also, have you tried simply to set value for Description field? Does this appear in the portal view?

As for setting request type once the item is created, you might try this: https://support.atlassian.com/jira/kb/automatically-set-request-type-when-issue-is-moved-or-created-via-jira/ (there might be some alternatives, but this seems to be the easiest solution) > basically, within Confluence automation you could set Label field or something like that, and then create Jira automation which uses condition on that Label field and edits Req. type as mentioned in the article.

Cheers,
Tobi

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

jira-service-management-cloud

jira-service-management