Our company-wide Jira Instance has 100+ projects across many subsiduaries. My team, with their 20 projects have 10 really useful custom fields that they need in addition to the standard items.
I can add these fields to a default screen set, and easily associate this set of screens (screen scheme) to my projects. If I clone a project, this screen scheme gets copied too.
I can do all of this without disturbing the other 90 or so projects.
But create a custom field? I cannot find such scheme paradigm. I have to manually, for each CF, select which project to add it to from a multi-select list of 100+ projects.
Create a new project? I have to update each of ten CF's to add that project to their context.
This is so stupid, I must be missing a trick. There must be some way of grouping my ten CF's together into a group, rather than selecting "global context" and adding this new CF to every project in the instance.
What have I missed?
The idea is to define an Issue Type Screen Scheme (ITSS) that has a few screens. Use that ITSS on all the projects that should have the same sets of fields in their issues. Then adding a new custom field just means adding it to a few screens.
Hey matt, thanks for the reply - that's EXACTLY how it looks to me; make all CF's global context, then make the grouping via ITSS;
it's easy to make a screen scheme for a project class eg:
And control the "visibility" of the CF's that way
It's not ideal, because if you wanted a CF in two of those ITSS's, but with different values, say, for a drop down, you'd still have to manage the project context by hand on the CF in question.
It's still a grade-a PITA, which I'm (not) surprised Atlassian hasn't addressed. I'm not afraid of automating it via some REST i/f - but there isn't one. Some hints of a possible hack via the Java API
I want to restate to ensure I'm understanding the ask.
You are creating a new custom field, and when you do you are selecting what projects to associate the custom field to? Or are you saying with a new custom field, when you create a context within that custom field, the process of mapping the specific context of that custom field to the projects?
If you are talking about the former, then Field Configurations is where it's at. If the later, there is no shortcut... but having as little difference between projects (ie standardization) is advisable to reduce administrator overhead on your system down the line.
At last year's summit there was a presentation by James Hunt entitled "5 Admins for 60,000 users" that dove into configuration efficiencies that I thought was very insightful and should be a goal of every large instance admin.
Hopefully this helps.
Yeah, my main take-aways and items I've looked at implementing are standardized project configs with 3-5 variants and setting up a 'shopping cart' style system for newly requested projects to go through and order the different existing configs and features they want. That was the part that I really liked the most.
Alternate thought (I thought about this last night as a method I used to use) If you are running JIRA Server, you could always edit the configs on the back-end and copy the CFs you want to use as a 'template' and then paste that config into your newly created CF. If you're good digging around and editing that way, and you have a lot of projects and don't want to always multi-select, that could save you a lot of time.
Badges are a great way to show off community activity, whether you’re a newbie or a Champion.Learn more
EaglePicher Technologies is a leading manufacturer of battery systems for diverse industries like defense, aviation, space or medical. As they operate in highly regulated industries, keeping a clear ...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs