does Associate an issue operation with a (New) screen - alter its association with current screen

[David Meyer]

Issues - Configure Screen Scheme >> Associate an issue operation with a screen

When I select this - I see a current association with a screen ("Demo" = live project).
If I select a new screen (LSHD - test project) -  does it break the current association?

Is it a 1:1 or can it be a 1:many ratio?

[Nic Brough -Adaptavist- · Accepted solution]

It might do, but there's not enough information in your screen shots to tell us.

The question is if you are in the same "screen scheme" in each screenshot.  If they are separate screen-schemes, you are fine.  If they are the same screen-scheme, then yes, you will be replacing what "create" uses.

[David Meyer]

They are in different screen-schemes.

But in "Configure Issue Type Screen Scheme (for LSHD: Jira Service Desk Issue Type Screen Scheme") -  I added the 2 Issue Types I needed and now I see the LSHD: Jira Service Desk Issue Type Screen Scheme in 2 Screen schemes - the bottom one (Demo) is live.

Will this affect that project?  I am not understanding the "screen scheme" and "Issue type" screen scheme clearly in my head.

[David Meyer]

NM my last bit. I realized 2 issue types use the new screen scheme and 2 use the other, so this is actually displaying correctly.  Your answer is appreciated.

[Nic Brough -Adaptavist-]

Sorry for the delay in response, I am not the most organised of people.

Short answer:  "They are in different screen schemes" means you are doing the right thing and you will not break the associations.  (And, as reassurance, even if you missed it and got the wrong scheme, you will not have done any lasting damage to your data, you can simply change it back)

To try to explain a bit more:

I think in layers of complexity in Jira project configuration.  It's all about the schemes.  Schemes tell a project how to behave.  There are three layers of complexity:

1. A scheme that tells a project how to behave irrespective of issue type
2. A scheme that tells an issue type within a project how to behave, whatever the user is doing with it
3. A scheme that tells an issue type within a project how to behave, depending on what they are trying to do with it

So some examples ("examples" because I might miss a couple - I'm tired today)

1. Issue type scheme, security scheme, permission scheme, notification scheme, priority scheme
2. Workflow scheme, field configuration scheme
3. Issue type screen scheme

Note that in group 3 there is only one thing, and it's what we're here for.

An issue type screen scheme has four things to think through:

1. At a project level, every project is configured with a single issue type screen scheme. 
2. The issue type screen scheme tells the project which screen scheme to use for each issue type (for example, "use screen scheme x1 for bugs and screen scheme z7 for everything else in the project")
3. The screen scheme tells the issue what screen to use for three of the four core things you can do to an issue:  Create, View and Edit.
4. The screen is nothing more than a list of fields to put in front of a user when they do something that needs to show them fields.

This seems complex, and, frankly, it is. It took me ages, and a lot of questions on this Community forum's predecessors to get my head around it.  I'm told I make it look easy when I'm showing it to people in real life, but I have still not managed to hit on a good document that explains it well enough for most, and I still remember struggling to understand it when I inherited my very first Jira (2.1-ish?)

But it gives us a huge amount of flexibility across projects and issue types, and the fact that it hasn't changed in well over a decade tells me that while it feels complex, that complexity could only be reduced at the cost of loss of flexibility.

[Nic Brough -Adaptavist-]

Thank you!  I'm glad you got there (and didn't need my cross-posted essay to get there either!)

[David Meyer]

Ah - but your breakdown in the concept of the layers is what I've been looking for in documentation, and a very good reference. Thank you!