Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

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

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?

 

current.PNGnew.PNG

 

1 answer

1 accepted

0 votes
Answer accepted

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.

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.

 

LSHD scheme associate.PNG

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.

Like Nic Brough _Adaptavist_ likes this

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.

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

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!

Suggest an answer

Log in or Sign up to answer
DEPLOYMENT TYPE
CLOUD
PRODUCT PLAN
STANDARD
PERMISSIONS LEVEL
Site Admin
TAGS
Community showcase
Published in Jira Service Management

Why upgrade to Jira Service Management Premium?

We often have questions from folks using Jira Service Management about the benefits to using Premium. Check out this video to learn how you can unlock even more value in our Premium plan.  &nb...

165 views 0 4
Read article

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you