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!

[David Fischer · Accepted solution]

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.

[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

[David Fischer]

Hi @Ricardo_Gomes ,

I tested myself and confirmed that the comment properties are not available on the Create transition. Can you add me to the Atlassian support ticket (you should have my email address from previous interactions)?

[Ricardo_Gomes]

Just added you to it.

In fact, I just got the latest comment from Atlassian where they are asking Appfire to contact them to put in a request for the issue to be fixed (it's all in the ticket).

Thanks @David Fischer !

[Claudio de Lima Sales]

Hi folks! @Ricardo_Gomes @David Fischer 

I will follow this discussion, as I also need this functionality. I made some unsuccessful attempts to validate an Internal comment entered on a transition screen.

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

issue.comments.filter(c => c.created > new Date().minusMinutes(1)).length > 0 &&
issue.comments.filter(c => c.created > new Date().minusMinutes(1))[0]
.properties.get("sd.public.comment").internal

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

If you could keep us informed about any solution proposed by Atlassian or AppFire, I would be very grateful.

tks

[David Fischer]

Hi @Claudio de Lima Sales 

Atlassian hasn't responded yet, but I expect a bug report will be created and... probably never fixed.

[Pablo Culebras [Jodocus.io]]

Slightly off-topic, but it is also impossible to retrieve the visibility settings of a comment for usage within the expression, such as:

issue.comments[0].visibility.value == "Developers"

Which will yield the error message:

Evaluation failed: "issue.comments[0].visibility" - Unrecognized property of `issue.comments[0]`: "visibility" ('visibility'). Available properties of type 'Comment' are: 'author', 'body', 'created', 'id', 'properties', 'updated

Oddly enough, if one just enters the following expression:

issue.comments[0]

The result does contain the property visibility (and jsdPublic, which cannot be accessed too) :

Object
    self:"https://example.atlassian.net/rest/api/2/issue/12345/comment/12345"
    id:"12345"
    author:Object
        ...
    body:"Hello world"
    updateAuthor:Object
        ...
    created:"2023-10-10T05:27:17.453-0700"
    updated:"2023-10-10T05:29:10.459-0700"
    visibility:Object
        type:"role"
        value:"Developer"
        identifier:"Developer"
    jsdPublic:true

[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.