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

JMWE - validator in JSM to prevent external comment from being added

Ricardo.Gomes

Hi,

I'm trying to create a validator using JMWE which would ensure that a comment entered during a transition is not an external/public comment, but an internal comment instead.

Basically, how this works in Jira is that in JSM, a pop-up will display when you have a screen configured with the transition, which will contain the Comment field. Being a JSM project, the Comment field will present itself with two tabs: 1. Respond to Customer, 2. Internal comment with the first one being active by default.

As you know, users often times (even with training) will simply add a comment and submit without double-checking which tab is selected (in this specific scenario, I want the comment to always be internal-only), which would cause trouble with our customers.

That said, regardless of which tab is selected, I wanted to use the JMWE validator to alert the user in case the wrong tab is selected.

In contacting JMWE support, they told this used to be possible with the following Jira Expression, which would force the user to input a public comment (which is the opposite of what I want) during a transition. However, it is not working as intended anymore:

issue.comments.some(c=>c.id == null) && (!issue.comments.filter(c=>c.id == null)[0].properties.get("sd.public.comment")|| !issue.comments.filter(c=>c.id == null)[0].properties.get("sd.public.comment").internal)

Not sure if this is a regression bug in JSM or Atlassian intentionally blocked this from working...

Any help will be greatly appreciated.

Cheers!

Accepted answers

David Fischer

Hi @Ricardo_Gomes

I'm afraid this is a change in the way JSM works. It doesn't seem to be making the "sd.public.comment" comment entity property of the newly added comment available to Validators anymore. From the Validator, you can access the new comment's body but not entity properties.

You can try opening a support request with Atlassian.

All comments

David Fischer

Hi @Ricardo_Gomes

You can try opening a support request with Atlassian.

Ricardo.Gomes

Thanks, David.

I opened a ticket with their support and they are looking into it to confirm whether that is a change in JSM or a regression of some sort.

Best!

Ricardo.Gomes

Hey @David Fischer ,

I've also shared this with AppFire via support, but just wanted to update this thread as well in case there's more people affected/interested, so here's the response I got from Atlassian Support:

"I've reviewed the issue with one of our most tenured engineers and also reached out directly to our Jira Cloud Ecosystem teams internally. I've not been able to get any further information on changes noted and as this is an integration per a 3rd party app, I've been directed to request that AppFire engage with the Ecosystem team directly and file a defect on their end. I've touched based with multiple teams, which have all directed us to the Ecosystem team so I think that is what will be required. As this worked previously and does not appear to be related to the Jira expression syntax, I do agree that it is likely a newly introduced issue and potentially a defect so I wanted to ensure there were no known issues but in order to make headway, further investigation will need to be driven by AppFire on this one.

Wish I could be of more help!

Kindest Regards,

Tj Webb
Atlassian Support | Cloud
ATLASSIAN"

Thanks!

Cheers,

Ricardo

Ricardo.Gomes

Hi @David Fischer {Appfire} ,

After a long investigation on the Atlassian side, it seems the issue would have to be addressed on the Appfire side.

Is that something you can help with/follow up on internally with your team, please?

Thank you!

Here's Atlassian response:

====================

Hello Ricardo,

Appreciate the follow up!

I've confirmed with the transitions team and the JSM teams that the comment entity properties have not had any recent changes and are available on comments even during the create process per the workflow transition. Based on this information and as this is based on a third-party integration, further investigation would need to be directed through those channels. It was my hope to facilitate this through reaching out to the teams directly to ensure there were no issues with the entity property availability, which has been reviewed by multiple teams. I also requested that this be worked on as well through the developer channels available to AppFire in parallel since the 3rd party workaround was reportedly working previously.

At this time, I've reached out to our Ecosystems team where AppFire would have engaged based on the integration with Connect and Forge module functionality per the API. As previously requested, it would be best to have AppFire file a defect directly based on their application and shared expertise on the use of the Jira expression syntax.

Kindest Regards,

Tj Webb
Atlassian Support | Cloud
ATLASSIAN

Claudio de Lima Sales

Hi!

Will we have a workaround using properties in the status, limiting comments public or internal?
Tomorrow I will investigate whether this is a possibility and then open a ticket with Atlassian and AppFire, too.

Welcome!

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

Quick Links

Find more posts tagged with

cloud

addon-com.innovalog.jmwe.jira-misc-workflow-extensions

jira-service-management-cloud

jira-service-management