nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Best Way to Implement New Sub-task Template While Retaining Old custom fields (Jira Cloud)

Sanam Malleswari

Hi Guys,

I'm exploring a change in Jira Cloud where there's a need to introduce a new template for sub-tasks with updated custom fields.

At the same time, it's important to retain the old custom fields on existing sub-task issues for historical reference and auditing purposes.

New sub-tasks should display only the new custom fields.
Existing sub-tasks should continue to show the old custom fields.
Avoid confusion and clutter for users during issue creation
Is creating a new sub-task issue type with a dedicated screen scheme considered the best approach?
Is there a way to hide or restrict the old issue type from the “Create issue” screen while still keeping previously created issues intact?

Has anyone worked through a similar scenario in Jira Cloud? Any best practices or ideas would be greatly appreciated!

Comments

Kimberly Anderson_ezmrbu

If I were in that situation, I would create the new template with a different name but as a Sub-Task type. That would cover all of the bullets listed.

Aaron Morris_49u8f7

Is there a way to hide or restrict the old issue type from the “Create issue” screen while still keeping previously created issues intact?

Yes, you can restrict users from using the old issue type on the Create screen, but you cannot remove it from the Create screen as long as it's part of the project's Work Item Type Scheme. (As far as I know.)

Example instructions: https://support.atlassian.com/jira/kb/how-to-restrict-the-creation-of-an-issue-based-on-issuetype/

This will give users an error message when they attempt to create a new item with the old issue type.

Matthew Berzinskas

"Is there a way to hide or restrict the old issue type from the “Create issue” screen while still keeping previously created issues intact?"

Least elegant:
- You can restrict the old sub-task type with a workflow validator (on the create transition), adding an error message or something to the extent of "This issue type is deprecated, please use whatever..."
  
  However, it will still appear, so can cause some confusion. There was a request to update the default sub-task type for all users, but it was declined.
  
  https://jira.atlassian.com/browse/JRACLOUD-40978
  
  The resolution notes, however, that once a user has updated the sub-task type they are trying to create once, all future sub-tasks they create will default to the most recently used one, so this "validation" solution should only really affect them once.
More elegant:
- If you use ScriptRunner, you can write a "Behaviour" script that dynamically hides the old sub-task issue type from the "Issue Type" dropdown on the "Create Issue" screen.

Rick Olson

New sub-task type, and the use of Adaptavist's Behaviours (to not show the old sub-task type), would me the way I'd tackle this.

JG Meillaud _

Hi Sanam,

Option 1 : New screen scheme

If you want to keep the old custom fields in your instance (if used on other projects, or if you want to still be able to do queries and access ticket history)

- View screen with both templates' fields

- Create/Edit screen with only the new template fields

➡️ You'll get your new template on the create form, as well as the editable fields. The old fields will only show if they hold values but they won't show if empty.

Option 2 : Get old fields data into the description with an automation

If you want and can delete the old custom fields from your instance (so you keep your instance clean and tidy, but no queries nor history)

- Create and run an automation that will replace old ticket descriptions with description + old field values

- Delete the old fields

Bad option : Creating another issue type

Creating another issue type is just bad practice in my opinion. It'll show in many places and will just confuse users and give them a feeling of a messy system. On top of that you'll need to have a specific workflow or some sort of custom restriction which mean more maintenance effort overall.

Sanam Malleswari

Thanks @Aaron Morris

Sanam Malleswari

Thanks @JG Meillaud _
I will check with option 1 and user might like this.

Sanam Malleswari

Thanks @Rick Olson
As part of my work not using script runner currently.

Sanam Malleswari

That's true. Thanks @Matthew Berzinskas

Welcome!

It looks like you're new here. Sign in or register to get started.