I've made a new "Create Issue" screen that I want to use for all "Bug" tickets in Project A. (I want Project B to use the Default screen when creating new issues.)
It is in step 4 that I start to lose my way. At one point, I somehow set it up so Project A uses my NewBugScreen for all new Bugs -- but now all my other projects use the NewBugScreen too, which I don't want! I can't seem to figure out how to associate the "Create Bug" Issue Type Screen Scheme exclusively with Project A.
(The screenshot below demonstrates exactly what I'm trying to do.)
Neither the "Configure" nor "Edit" links take you to a screen that allow you to associate a project. (Which is why, in step #4 above, I tried to do it from the Project admin screen. But if the path is there, I couldn't find it.
Here's the link on how to do it. You would need to go into your project as administrator and amend the issue type screen scheme.
See the section - choosing a project's issue type scheme
A few other points to consider, as you have accidently rolled out the new screen to all your projects.
1. Check that the new screen scheme associates the create issue screen to NewBugScreen
2. The screen scheme is not associated with any other screen used by other projects
3. Check that the issue type screen scheme "create Bug" associates Bugs issue type to the screen scheme CreateBugScreenScheme
My bad. the url was incorrect
Here's the right one
btw, did you manage your way through the issue?
well, I eventually got it to work, but unfortunately, I don't know how! I basically started over, trying to follow the Overview Diagram in reverse: I started from the perspective of the Project and created a Project-specific Issue Type Screen Scheme, and a Project-specific Screen Scheme. Somehow it all just worked this time around!
Frankly I would be embarassed if I'd been the author/developer of the administrative tools that are supposed to enable you to add new screens/screen schemes and issue type screens. This is absolutely the least user obvious design I've ever encountered. Following pages of tutorials and I still can't get a new screen to be properly associated to an issue type on a project.
I think I'm finally getting the hang of it now, but I feel your pain. Just grokking the underlying concepts is half the battle. I have found that it is really helpful (during configuration) to carefully name everything precisely (it helps untangle the hairball). So for example, I would name my screen "ProjX Create Screen" or "ProjY Default Screen". Then, to understand how everything connects together, here is an outline that might help:
SCREEN-- Maps fields to a named "screen" (e.g. "ProjA Create Screen" contains the "Description" Field.)
SCREEN SCHEME-- Maps screens to Issue Operations (e.g. The "Create Issue" operation for ProjA will use the "ProjA Create Screen"). Operations are "Create", "Edit", "View" and "Default". The button to associate an Operation with a screen is in the upper-right corner.
ISSUE TYPE SCREEN SCHEME-- Allows you to assign one screen scheme to Bugs and another to Test tickets, for example. (So any given project can have a number of screen schemes; one for each Issue Type, if desired).
Then, to actually ASSIGN an Issue Type Screen Scheme to a particular project (the original question I posted):
I agree 100% with George Worthington. The interface is a complete nightmare. Completely non-intuitive.
It also makes me laugh in frustration to read the "helpful" directions on the page that says "This scheme can be used by one or more projects, the field configuration specified for each issue type will be applied to the issues in these projects." but then does nothing to direct you to HOW you go about connecting it with a project. You're left to your own devices to search and search for a solution in the abyss of screen scheme confusion-land on atlassian.com.
I am sympathetic to Michael's complaining/venting. In my experience when multiple users say a feature is confusing and poorly designed its time to take a look at reworking it. Micheal, I recommend reading Kevin Mote's post above ... a few times :). By the way, I did get the schemes working but it was not without pain. I appreciate their flexibility and power now.
I have to agree. As PM that is just trying to get the tool set up so I can drive the product forward, I am dismayed that the deeper I get in to this tool, the more I become aware of how convoluted and byzantine the admin tools are. The help pages and community are better than just poking around and trying to guess the intent of the Atlasssian design team, but not by much.
I suspect what would really help is some sort of document that shows the hierarchy of the various Jira elements (project, board, workflow, scheme, etc) and how they control or contain indicators like status, rank, etc.
Agree with all the frustration comments. Even now 5 years later it's not any better. Surely the brilliant minds that conceived the flexibility and power of JIRA could help simplify it's usage!!!!
(I've administered JIRA for about 3 years but now coming back after a 4 year gap)
In all but the most simple cases, you can have "simple" or "flexible". Pick one.
Atlassian have gone for "flexible". Jira is complex when you are an admin, yes, but if you don't have this complex/flexible thing, you can't make it work for your users (unless they all do everything in one single standard way you can dictate to them, in which case, you should be using a tool which restricts them to that single process, like <name legacy tool here>).
There's no "rejection" of a problem, just re-iterating what has already been pointed out. It's "complicated" because it's flexible. Gives us a steep learning curve, but I've never worked out a way it could be simplified, because there is nothing in the system of schemes that you could remove without losing the flexibility.
I would argue for throwing away field configuration schemes as their functions could be absorbed into other areas, but that's about it.
I'm so glad it's not just me. I've spent all afternoon clicking through all these screens trying to figure out how to do associate an issue type scheme with a project, but following Kevin's instructions figured it out in 5 mins.
If it needs to be complicated and not very intuitive to allow us the flexibility Jira offers, then the help section needs to be MUCH better, both in surfacing the relevant pages when searching for how to do something, and simplifying instructions on said page. If Kevin's comments had been in an easy to find guide, I'd have spent much less time tearing my hair out trying to figure out how to do it.
From scratch, and assuming you have a project with tasks and bugs that should have different screens:
I put this together if starting new screen from scratch for new project to be separate.
1. If you want new screens, new project, new fields, separated from service desk for example. E.g. creating a list of Sales Leads totally separate. Create a Sales Project and Leads Screen, which may have Opportunities, Contacts etc screens in the future.
2. Create all custom fields for new leads screen
3. Create new screen LEADS_SCREEN and add all fields above
4. Create new screen scheme LEADS_SCREEN_SCHEME selecting NEW_SCREEN above. Use a new screen scheme for each new screen
5. Create new issue type LEADS_ISSUE_TYPE.
6. Create Issue Type Screen Scheme LEADS_ISSUE_TYPE_SCREEN_SCHEME selecting LEADS_SCREEN_SCREEN_SCHEME.
7. Edit and select issue type LEADS_ISSUE_TYPE.
8. From Issue Type Screen Scheme LEADS_ISSUE_TYPE_SCREEN_SCHEME press top right "Associate an issue type with a screen scheme" button and associate Issue Type LEADS_ISSUE_TYPE with LEADS_SCREEN_SCHEME. This allows an issue type to open different screens for the same operations (Create, Update, Delete).
9. Create new Project LEADS_PROJECT and associate with Issue Type Screen Scheme LEADS_ISSUE_TYPE_SCREEN_SCHEME. If you needed to change the project afterwards it is very tricky. Go to the Project and press the top right Actions and "Use a different Scheme" which associates the project with another Issue Type Screen Scheme. After this is selected, the screen associated should be listed here with an edit.
10. Associate new issue type with LEADS_PROJECT
Once you have created and configured an issue type screen scheme to your desired settings, you can now associate the scheme with a project. This will apply your chosen screen scheme to each issue type within the selected project.
Thank you Mohd! I've been trying to associate the Screen Scheme with the Project for the last 2 hours, following each link I've found and still failing to get the result. This finally worked. I have to agree with the majority view in this thread. After over 20 years experience in relational design, why the Atlassian developers have chosen to structure the system this way is beyond me. Come on guys, please step up and redesign this interface, it's dreadful and ruins a good product.
I can say IMO, this whole design is very un-intuitive. Why cant there be a list of fields, and these are associated with a jira issue type, not associated with a screen that couples a issue type and action.
I like most people want to create some fields, tie them to an issue type and project, give the fields some config - mandatory, default value etc. for each project. Then these fields get added to some screens that tie an action and issue type. This would allow us to hide some issue type fields from certain screens.
The current design decouples all items (ie fields, screens, issue type, issue operation) by abstracting another level - the scheme levels. So you can basically do anything with anything, but this is not the use case most of us want, and adds a mind bending amount of confusion. My advice to beat this obfuscation is to draw a nice diagram, do everything in one project at a time (yes I know - lots of wasted effort - but better than breaking everything), and finally test everything in a dummy project first,
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