Forums

Articles
Create
cancel
Showing results for 
Search instead for 
Did you mean: 

conditional logic for smart value update

Dmitry Alabyan
Contributor
April 5, 2025

Good day, community!
most probably, this is a question @Bill Sheboy is able to answer as an expert=)

I have a following case:
we are using a JWM project to track campaigns for different clients.
With sub-tasks representing the costs of different publishers.
Costs are then displayed in the description of the parent.

Plus, the team uses the description field regularly, so I my edit issue is looking like:

{{issue.Description}}

Publisher costs: {{#issue.subtasks}}{{summary}} {{✍ Publisher Costs}}, {{/}}

BUT
that only works well for 2 iterations.
e.g. if (and that is a common case) there are multiple subtasks added at some later point,
I have duplicates and even triplicates of the info, since {{issue.Description}} retains all the info prior to the update.
What I a interested in is how to keep only the original description input from the team with subtasks values being updated dynamically.

P.S. if-else branches wouldn't fit, as it's not an option within another branch (see screenshot). Maybe some re-fetch solution?

Any advice is highly appreciated!

image.png

1 answer

3 votes
Walter Buggenhout
Community Champion
April 5, 2025

Hi @Dmitry Alabyan,

Just thinking outside the box for a second here ...

Is there any reason why you need the Publisher costs to be in the description field? If this is important information, why don't you set up a separate field for that information? It would make the content quite a lot easier to find and probably also solve your duplication problem.

Hope this helps! 

Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
April 6, 2025

Hi @Dmitry Alabyan 

I agree with Walter's suggestion as the separate field may raise the visibility of the information and make it easier to manage.

 

If you still want it all in the Description of the parent work item, the "fix" is to add a delimiter to the Description so it can be parsed.

For example, let's assume the field looks like this before an update:

Here is some stuff about the campaign!

Publisher List:

* Publisher A info: 123 (costs)
* Publisher 2 info: 456 (costs)

When updating, everything before the delimiter / section title could be extracted before re-applying the subtask information.

{{issue.description.substringBefore("Publisher List:")}}

Publisher List:

...iterate over the subtasks to add their information

 

Also, I note your rule is triggered on a change to the Publisher Costs.  Should that also trigger when the Summary of a sub-task changes as it is included in your parent work item's Description?

 

Kind regards,
Bill

Dmitry Alabyan
Contributor
April 7, 2025

yes, totally with you both on the separate field topic - but sometimes it is what it is. they are displayed in a separate field for calculation purposes, but the team needs them aslo stated plainly in the description.

so, thank you very much for the delimiter notion, I think this would well be the way!

no, the publisher cost field is separate between the two hierarchies, so this is kept clean as possible, triggers as intended

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
TAGS
AUG Leaders

Atlassian Community Events