Global automation: clone everything always - should work for everyone in the company

[Bastiaan]

We are trying to make a global automation, that allows everyone in the company, to use Jira to handle recurring tasks, by simply adding the keywords, weekly, monthly, quarterly etc.

I have made a global automation...

------------------------------------

> When issue status is set to "done"

> and label contains "monthly"

> Clone issue into same project

    same issue type

    summary = {{issue.summary}}

    date {{now.plusMonths(1).firstBusinessDayOfMonth}}

    // copy XYZ from trigger etc. etc.

------------------------------------

However I want everything copied, a real clone except the date, and of course the checklist / task-list unticked... 

how?

mentioning all the possible fields throws errors, because some people use epics, some people call them categories etc. Some people might have custom fields in their project, some don´t.

[Mark Segall]

Hi @Bastiaan and welcome to the community!

If you don't specify fields in the clone action they will copy as is so you should only receive errors if you're explicitly capturing fields in your clone that are not available on every project.

As for the checklist, I'm assuming this is simply a custom field leveraging the out-of-the-box checkbox field type.  If so, you should be able to do something like this to clear them out and ensure that it only is performed against relevant issues:

1. Add an If condition to your rule after you clone the issue to evaluate whether the custom field exists (e.g. project in x,y,z or issue type in a, b, c).
2. In the If condition perform an Edit Issue against {{createdIssue}}
3. use more settings with the following JSON to clear out the checkboxes:

   1. {
         "fields":{
            "<your field name>" [
            ]
         }
      }

[Bastiaan]

I removed all the items from my copy list, that resolves the error, and epic etc. are still copied correctly, however checklists are not copied to the clone....

How do I make sure that extra´s like (normal not smart) checklists are cloned also?

If I specifically mention them, won´t they create errors for tasks that do not have one

[Mark Segall]

Glad to hear this is a few steps closer.

If I specifically mention them, won't they create errors for tasks that do not have one

Not if you handle it the way that I mentioned in my last post.  What I'm proposing is that you clone the issue, then under a specific condition (you'll need to define where the checklist is used), you branch into the issue you just created and clear the checkboxes.

Again, I'm working under the assumption that your checklist is using the native checkbox field type. If you're using a 3rd party app, they can be a bit finicky, resulting in more of a challenge.

[Bastiaan]

The issue is that we have many teams and many boards and we were hoping to just build a "copy everything in this task to a new recurring instance of the task" that could be a global rule for the whole company. 

"tag your task with weekly and it will work with all standard elements" kind of a thing. On the functional ongoing tasks in all the different team "projects" (which aren´t really projects evidently) etc.

[Mark Segall]

Can you share a screenshot of your current rule so I can get a better sense of where you're hitting a roadblock? 

I have a project where I had to do something similar... I needed to clone issues to other projects (dozens of options), but found that insight fields weren't cloning and those insight fields were not present on every project.  I ultimately created an IF condition immediately after the clone action to check if the created issue had the insight field in its screen configuration.  If true, I added a branch into the created issue and an edit issue action to copy the insight field from the trigger issue to the newly created issue.  This has worked very effectively for my use case.

[Bastiaan]

First of all, thanks for your continued support, it´s very much appreciated...

I don´t understand why all the standard functionalities of jira (so not from plugins) isn´t just copied if it is there..

Basically all we want for recurring tasks, is that the exact same task is recreated for in an X period. We have weekly, monthly, quarterly etc.

I am not that experienced with writing jira JQL, just some basics. Not in this conversation, but I do do research and I keep finding answers here and there I want to try with "write some JQL with XYZ in it", which is then really not that useful since I don´t know the rest, but that´s my learning opportunity I guess.. :-)

[Mark Segall]

No problem... We'll get there.  😉

So, let's take it back a step and build out the business logic...  Is there a specific issue type or list of projects that would utilize your checklist field?

[Bastiaan]

So lot´s of people have recurring tasks, from customer service making weekly and monthly reports or contacting business partners for feedback periodically, Checking continuous improvement topics monthly, to sales people doing monthly follow ups with their accounts, to finance people to product developers doing quarterly product checks etc. etc.

since we use Jira for both usual project work (developing new projects) as well as these recurring tasks, we use jira also for work planning and to see how much is on someone´s plate at any given point.

therefore to have recurring tasks being copied back to the backlog, seemed like a logic choice. 

quite a few of these recurring tasks have checklists, do this, then to that, make sure you check X, ask Y for input, then finalize report or similar... Especially recurring tasks often exist of a repetitive list of subtasks in fact.

Maybe not entirely what Jira was once designed for, but common business practice nonetheless I´d think.

[Mark Segall]

The main thing is to identify how we can isolate which projects/issue types have checklists associated, or... If most do, we need to isolate which ones DON'T have checklists.  That's where the IF/ELSE condition comes into play.  If we can easily identify which issues have that checklist field, we can set it so that field gets cleared out on the newly created clone.