How to standardize and manage issue types

Frank Kopankiewitz

We have defined a set of issue types that each has an associated workflow.  There are also custom fields associated with that issue type.  We want to be able to have projects use those definitions.  I also want to be able to update a workflow and have it propagate out to all the projects that utilize the definition.  Is there any best practice documentation or recommendations to accomplish this?  I believe the schemes are the key here, but I'm struggling to figure out how the Workflow Scheme, Issue Type Scheme and Field Configuration Schemes. 

When trying to move to a project, i can associate the Issue Type Scheme and it picks up the issue types.  Great.  But the workflows associated with each don't get picked up.  in the project is associates all the new issue types with a "simplified workflow".  So there doesn't seem to be a permanent link between a workflow and an issue type.

Any suggestions would be appreciated.

 

Inactive Stephen

Hi @Frank Kopankiewitz

Projects have a number of different schemes which can operate either in synch or separate from one another. A good way to see the different schemes in play is to visit a project's settings page, where you'll see schemes for Issue Types, Workflows, Screens, Field Configuration, Priorities, Permissions and Notifications.

This means in your example you have changed the Issue Type scheme for a project which is fine - but it's still operating on a different Workflow scheme. You'll need to either:

• Change the Workflow Scheme for the moved project to the one you created or...
• Add the correct workflows to the project's existing scheme

^ Either way will fix the issue. This might not be isolated to workflow - if you have custom fields, you might need to edit the Screen Scheme also to include the screens for these new issue types for example.

There is no definitive best practice here - here's two options you could explore, using workflows as the example...

• Set the same workflows / scheme for all projects or...
• Require each scheme to have the same workflow for certain issue types - but allow them to be flexible on others

^ Either method would ensure for specific workflows, updates to them are applied to everyone. You could apply a similar methodology to screens, etc. It comes down to how your teams work best - do they all work in a similar manner? How much flexibility do they need in their projects?

Pro-tip on new project creation - whilst there are a lot of default schemes you can edit, not all are available yet (see this issue for default workflows). You can however choose to copy the project's configuration from an existing one - select "Create with shared configuration" on the first screen after you click "Create project" and choose a project to copy the configuration from. Saves you the time and effort of changing all the schemes post-creation.

There is some great information on projects and schemes in this Confluence Page.

Ste