How to automate issue description update in multiple spaces

[Rob Peters]

Hello Community,

I am looking for a solution for the following situation:

We create for each customer project a own Jira space. This is an empty space with the right setting/schemes using Jira Automation (REST API). The empty space is then filled with a default project structure (a set of 60+ work items in a specific hierarchy) using Templating.app. At the moment we have 20 customer space, but this will soon grown towards +200 space. Each of them is created based on the default project structure. 

What i want to achieve is that a admin is able to centrally update the description of a specific work item in all +200 spaces (all these +200 space will have that specific work items). I already discovered that bulk edit doesn't work on the work item description. I prefer to solve it in Jira automation without using any third party apps. 

In short I want to deploy an updated description text to all spaces, to all work items which mean the criteria.  

Thanks. 

[Trudy Claspill]

Hello @Rob Peters 

Here are some things to consider in your desired solution.

To have a single rule that affects multiple Spaces your rule will have to be created by a Jira admin. And the Actor of the rule will need to have sufficient permissions in the affected Spaces to edit the Description in all affected items.

If you want the rule to be run on-demand it will either have to be a Scheduled rule that only a Jira admin would be able to access to run on-demand, or it would have to be a manually triggered rule that could be triggered from a work item.

What is the criteria for selecting the items to be updated in the +200 spaces? Will this change from one run to the next? If so, the person executing the rule will need to be able to edit the rule, or the rule would need to be manually triggered with a prompt to ask the user to provide the JQL to select the work items to modify.

There are limitations on how many items can be processed in a rule. Refer to 

https://support.atlassian.com/cloud-automation/docs/automation-service-limits/

If the items are selected by a JQL in a Scheduled trigger than up to 999 items can be processed in a single run. If you anticipate needing to update more than that many items you would need to factor in a way to track which items were already updated so that they would be skipped in the next run of the rule.

If the rule is triggered manually then the items would need to be retrieved by a Lookup Work Items action, and that is limited to retrieving no more than 100.

Which type of admin are you referring to when you say you want "a admin" to be able to do this? Are you talking about a Jira admin or a Space admin?

What type of update will need to be made?

1. Does the Description currently contain text that is formatted in any way, contain images, links, etc. or is it just plain text?
2. Will the "update" be an entire replacement of the existing text? Or are you wanting to present the existing text to the user to have them modify it, then apply that to the targeting items?

[Trudy Claspill]

I may have an incorrect statement in my original reply. 

Where I said a manually triggered rule would have to use a Lookup Work Items action to lookup the issues (via JQL) to modify, that may not be the only method available.

It might be possible to use a branch: For Each > Related items > JQL

The JQL for selecting the issues to be changed would be supplied.

I think with that method you could get up to 999 items.

[Rob Peters]

Hi Trudy, 

Thank you for your reply!

I am one of the organization admins within our company, so permission will not be an issue. In our situation a manual trigger would work the best, since we only have to need to update occasionally. The search criteria should be flexible but will be always based on the item summary. It would be great if input could be given using a prompt but if to complex or not possible a manually interaction if fine (it already saves a lot time and reduces the risk of errors). 

I want to replace the entire description for a new description, the new description will be combination of text and a link (to Confluence). 

[Trudy Claspill]

I was correct that Lookup Issues action is limited to 100 issues, so if you anticipate needing to edit more than 100 issues you will have to use a branch.

If this is built as a manual issue then when it is triggered from an issue that issue itself will be excluded from the updates. You would need an extra action to edit the trigger issue also.

Would you be triggering this (manually) from an issue that you also want to update?

Would the set of issues to be updated all have the same Summary as the trigger issue? Would it be a full match, or does your issue creation process add some project-specific text to the templated Summary? Would the summary of a given issue ever also be part of a summary of an issue you don't want to update? i.e.

Summary of issue #1: "Build a house"

Summary of issue #2: "Build a house with two stories"

...where you want to change the issues that have their Summary set to just "Build a house"?

The basic rule would be something like this:

This rule prompts for the JQL you want to use to select the issues to update, and the new text you want for Description.

It will do a full exact match on the Summary field when the JQL is entered as shown above. And here is the result.

There are additional nuances to considered as I mentioned above. If you want to trigger the rule from an issue you want to include in the update set, the rule needs an Edit action outside of the branch to edit the trigger issue. If the trigger issue summary is an exact match for all the issues you want to change, and you don't want to add any other criteria, then you don't need to prompt for the JQL.

The rule will have to be multi-project scoped. You'll need to consider if you want it to be Globally scoped or if you want to explicitly specify the target projects in the scope.

I would also consider if you want to exclude from the change set issue that are already completed or in other statuses that should preclude a change to the Description.

[Rob Peters]

This is exactly what in need. Will fine tuning and optimize towards our needs and requirements. 

The idea was to trigger the issue from a Jira Administration space in which we receive the request to update the description, this is a bit challenging to fix but i am satisfied with how it works now. 

The update will then only be done on the space which match the space category to make sure that only those spaces are updated, so I included the category in the in the JQL search query and works fine. 

I also included a Confluence link. When i normally paste this in the description Jira automatically changes the link into a Inline representation. With the automation it will show the URL only, which works but would be nice if displayed as Inline link. Is there a way to fix this?

[Trudy Claspill]

The URL that I used in my example came through as a clickable link. Is that not the case for the Confluence URL you paste?

I will test with a Confluence URL to see what happens, and get back to you.

[Alex Ortiz]

@Rob Peters 

Try doing this wild, but crazy workaround that should work for you.

https://community.atlassian.com/forums/Jira-questions/Bulk-Change-Description-Field/qaq-p/897762

[Trudy Claspill]

The one from Vincent, nested within Mohamed Riza's response thread?

That is an intriguing workaround.

If the +200 projects share a workflow scheme it could be manageable. If they do not, then the change would need to be incorporated into the existing Spaces' workflows and into whatever is being used to create the new Spaces.

[Alex Ortiz]

There were a few options in there, but Vincents was the one I tried and confirmed worked.  

[Rob Peters]

Hi Alex,  

Thanks for your reply. 

I will look at the proposed solution. 

@Trudy Claspillall spaces share the same workflow. 

@Alex Ortiz love your Youtube Channel, helped me a lot :-) !

[Alex Ortiz]

@Rob Peters 

Have you tried using the variables feature in the templating.app and make modify the description before the work is created?  In the Templating app, when you use variables, it will prompt the user to provide text/info before the work is created.

Otherwise, as long as you have a good JQL, you should be able to do the transition trick mentioned in the article.

[Rob Peters]

@Alex Ortiz 

Yes, I am using the variables feature to add project specifics like start/due dates and assignee's. This will only fix it for that specific project but i need to update all excising spaces, to guide the users of the space to the correct landing pages in Confluence for example. 

I still have to check the article you shared, i am also interesting what solution Trudy will share. 

[Alex Ortiz]

If all you need to do is "update" information, why don't you just create a new custom field of type paragraph and bulk edit that?  Does it have to be in the description??

Also, could you add the information as a comment? I think you might be able to bulk update comments? 

[Rob Peters]

It might work, but I’m not sure whether that custom field would appear in the Templating.app where I create the issue template that gets deployed for each new customer project.

To be honest, I’d prefer to set up an environment for users, especially infrequent ones, where the right information is always shown in the same place. When things move around, it can quickly become confusing.

That said, I do appreciate your help in finding a simple and easy solutions.

[Alex Ortiz]

Custom fields, as long as they are on your screens, should show up in your templating.app.