ADF support in Jira Expressions

Jira Development Jira Cloud
,
1

Hey, it looks like not all ADF fields are seen as RichText in Jira Expressions.

I created a multiline text field:

{
"id": "customfield_10061",
"key": "customfield_10061",
"name": "test text field multi line",
"untranslatedName": "test text field multi line",
"custom": true,
"orderable": true,
"navigable": true,
"searchable": true,
"clauseNames": [
"cf[10061]",
"test text field multi line",
"test text field multi line[Paragraph]"
],
"schema": {
"type": "string",
"custom": "com.atlassian.jira.plugin.system.customfieldtypes:textarea",
"customId": 10061
}
}

And typeof(issue.customfield_10061) says the field is of type Map instead of RichText. As a result it’s not possible to use the plainText attribute. Can all the ADF fields be supported by the Jira Expressions?

2

Hey @daniel2,

Custom fields in Jira expressions are treated a bit differently than other fields, in that they are returned in the exact same form as in the Get issue REST API, regardless of their type. In this case, the REST API representation of a rich text field is a JSON object, and this is what you’re getting in Jira expressions (where JSON objects are represented as maps).

Note that depending on which version of the API you’re using, you’ll get different results. Version 3 returns ADF objects, while version 2 – wiki markup. Perhaps using version 2 would solve your issue?

Other than that, I imagine we could introduce a RichText type constructor that would accept ADF objects, such that you could write new RichText(issue.customfield_10061).plainText. Feel free to create an appropriate feature request in the ACJIRA project if this is something that would interest you.

2 Likes
3

Hey @kkercz ,

The workaround you suggested kind of works but in our case it may be too problematic to switch to the old version of API just for this feature.

I created a feature request for your consideration [ACJIRA-2426] - Ecosystem Jira

The RichText constructor could work if there was a way of telling that the field is ADF object. Otherwise we need to somehow establish it externally. At the moment we can simply do if typeof(RichText) then myfield.plaintext else 'somethingelse'

4

Hi @daniel2 ,
actually, if you’re manipulating text fields in your Jira expressions, I would strongly recommend you use the V2 REST API to execute your Jira expressions, because ADF is useless in Jira expressions (like in any scripting use cases). And you only need to use the V2 API for that - you can mix and match V2 and V3 API calls freely.
Generally, unless you’re implementing a rich text editor, you’ll want to stay away from the V3 API, because ADF is a pain to manipulate.
Just my two cents,
David

2 Likes
5

Hi @david2
Thanks for this recommendation. It looks like we should simply switch to v2 for now (until we actually need the metadata from ADF).

Regarding ADF, are you saying that it’s not really feasible to extract meta-information from ADF structure using Jira Expressions? Is it about hitting the evaluation limits?

6

No, you’ll be able to extract some info from ADF (but only on custom fields I think - I don’t think the full ADF is returned for standard fields like Description), but the structure is complex and hierarchical, so it’s hard to parse it using Jira expressions which don’t allow recursion (because they don’t allow functions). It all depends on whether you need the actual text.

7

To be fair, following the recent advancements, you can define functions now. For example, this expression returns 2:

let myFunction = x => x + 1; myFunction(1)

These functions can’t be recursive though, so you are right that fully processing structures like ADF isn’t really feasible.

1 Like
8

@kkercz that’s nice! You should make it clear in the documentation, because I noticed the new variable assignment syntax but didn’t realize it supported assigning lambdas…

1 Like