With our app Deep Clone for Jira, we clone a lot of issues – about 200,000 per week! The first step when cloning an issue is to create the cloned issue. It is also the most critical step, as we’re not able to proceed with cloning if the issue cannot be created.

Number of issues cloned by Deep Clone, per week

Number of issues cloned by Deep Clone, per week

Since a big part of our Deep Clone codebase is dedicated towards getting the “create issue” step right, I thought it would be interesting to share what exactly we’re doing to make sure that it succeeds. It turns out that there are a ton of edge-cases to consider.

Check for missing required fields before creating a Jira issue

It starts even before our internal “clone task” gets running. Already when selecting the target project and issue-type where the cloned issue is supposed to end up, we check if the original issue provides all field values for the required fields. There are two sources of required fields:

Required fields can also be added in a workflow validator

Required fields can also be added in a workflow validator

There are also more workflow validators that need to be considered when creating the issue, but we’ll focus on required fields for now. If we detect that the original issue doesn’t provide a value for any required field, we show them as “missing required fields” and don’t let the user start the clone since it would fail. The user can choose a fallback value for issues where the value is not present using our Field Editor.

The create issue screen in Jira.

The create issue screen in Jira. Note that required fields are marked with an asterisk *

Those required fields are usually present on the “Create issue” screen, but Jira doesn’t check if they actually are. If that’s the case, the project configuration is essentially broken since there is no way to create a valid issue. We show those as “hidden required fields” and let the user know that the project configuration needs to be fixed before an issue can be created. This often happens on newly created projects where the user has not created any issues yet, or if the project configuration has recently been changed.

We also need to ensure that there are valid values to be chosen from select-list fields, such as Components, Versions, or custom fields with dropdown values. For Components and Versions, we do allow to create those in advance before creating the issue, so it doesn’t fail if those fields would be required. The same is true for the “Sprint” field.

Components and Versions can be created if necessary

Components and Versions can be created if necessary

Make sure the Assignee is an “Assignable User”

Another common pitfall when creating an issue is the “Assignee” field. It has its own “Assignable User” permission, which determines which users are allowed to be assigned issues. If the target project has different permissions, or the original issue was assigned to a user which no longer has the “Assignable User” permission, we might need to use a different user. 

The solution depends on the “Allow unassigned issues” option in Jira’s general configuration:

The solution depends on the “Allow unassigned issues” option in Jira’s general configuration

If unassigned issues are allowed, we can just create the issue as “Unassigned”. However, if unassigned issues are not allowed or if “Assignee” is a required field, we need to provide a valid assignable user in order to create the issue. The last option is to use the project’s “Default assignee” – if it’s not set to “Unassigned” and is a valid “Assignable User”. Otherwise, we cannot create the issue and show an error to the user, which only happens very rarely. In that case, the user can override the Assignee using the Field Editor, as already mentioned regarding the missing required fields above.

Assignee Statuses

Prevent throttling errors when creating a lot of issues

If Jira is very busy, or we’re cloning a lot of issues too fast (Deep Clone supports cloning up to 100,000 issues with Bulk Clone), it might respond with an intermittent error. Over the years, we have seen quite a few different possible error messages, e.g.:

  • A “429 – Too Many Requests” response.
  • “This Jira instance is currently under heavy load and is not able to process your request.”
  • “Unable to establish a connection with the database.”
  • “FATAL: too many connections for role …”
  • “We can’t create this issue for you right now, it could be due to unsupported content you’ve entered into one or more of the issue fields.”

Response “429 - Too Many Requests”

Response “429 – Too Many Requests” as explained by http.cat

Now what?

Hopefully, you were able to create your issue quicker than it took you to read through this blog post. At least, you know which pitfalls you might encounter and how to resolve them swiftly. However, there are a lot of other edge cases to consider that we don’t have the time to dig into today. 

In our case, after having successfully created the issue, we continue editing and adjusting the issue until the cloned issue resembles the original issue as much as possible, e.g.:

  • Editing issue fields not present on the “Create issue” screen
  • Adding attachments, comments, work logs, watchers and votes
  • Adding issue links, remote links
  • Cloning issue properties used by other Jira apps
  • Cloning the issue status
  • Cloning subtasks and other issue hierarchies like Epics and Initiatives
  • Temporarily removing reporter and watchers to prevent notifications from being sent – another complicated topic that we might revisit in a future blog post

If you haven’t used Deep Clone yet to satisfy your cloning needs, you might also want to check out Deep Clone for Jira on the Atlassian Marketplace. It can be evaluated for 30 days and is permanently free for Jira licenses with up to 10 users.

Cookie Consent with Real Cookie Banner