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
Highlighted

Too many Screens Schemes

Hello Community,

I have inherited a Jira Server instance to which I do the admin. It’s a mess . . . just to be blunt and to the point.

I had a request to import a CSV file but the fields were not there. Fine! I went to the Screen Scheme under the Issue navigation and horror . . . 600 plus Screen Scheme Names. I have never seen such a mess!

I later discovered that a new created Jira Project doesn't create its own Screen Name. Wonderful! Chaos on top of Mess

So, I did find the “Default Field Configuration” to which I have added the required fields. I did not find a scheme with the Project’s name nor its Key. Nevertheless to say, the fields are still missing in the import. I did also try the External System Import without success.

In short my questions are:

  • How to solve this import issue?
  • How to clean all the Schemes and got only the ones I need?
  • How to export the list of projects using a specific Scheme?
  • Pitfalls in consolidating such mess?

I will also fill this either as BUG or UNWANTED FEATURE because Jira how it works it is a real mess and makes the Admin impossible.

 

Any input? Please?

 

2 comments

The complexity that Jira lets you create is a function of its power.  If you want to reduce the complexity of the system, you pay the price of loss of flexibility.

Your story is a familiar one to experienced Jira admins - we've all inherited systems that are a mess like this.  It's because too many people were given access and/or a lack of governance.  Admins have have said "it's flexible and allows me to be different to my colleauges so I'll just change it without worrying about everyone else"

 

  • How to solve this import issue?

Temporarily, make it worse.  Create schemes that include all the fields you want to import, and others you want, apply it to the project that wants the import, then import the data.

  • How to clean all the Schemes and got only the ones I need?

Use the "delete" option in the inactive schemes to start shortening the schemes, then find schemes that are used a lot (again, you might want to use new ones), and get your project owners together to discuss which smaller set of schemes you want to standardise on.  Move all the projects to those, and then delete anything listed without a project.

  • How to export the list of projects using a specific Scheme?

There's no export, but the list of each type of scheme shows all the projects using it.

  • Pitfalls in consolidating such mess?

Users being told they have to work in similar ways can encounter resistance, but pointing out that your reporting and processes are probably totally incoherent can help

  • I will also fill this either as BUG or UNWANTED FEATURE

Don't bother, it is this way by design, it's not going to change.  "Hey, can you please reduce the power and flexibility of your product making it less useful to most of the users" is not something most product owners will buy into.

Like coiram likes this

Hi Nic,

Thank you for your reply.

I start from my last question and your reply.

I've been working in Software Configuration & Change Management field for 18 years and to date, Jira is one of the most cumbersome tool I've used. It is good, but it has no Governance. Also "it is by design" doesn't mean it should be considered a feature but rather it is bad design.

Governace has its meaning and it is considered to bring order to chaos. If a tool doesn't do that not it is its purpose, let's go back to pen and paper the result will be the same . . . and it would cost less, much less.

It is also true that testing a software application costs money, hence it is left to the end-user to report problems. But also selling what the consumer wants doesn't mean that is a "good" product . . . plain and straight opinion.

So if the last sentence it is true, on BUGS:

If power and flexibility of a product means more than 300 projects got changed in a split second because of ripple effect of a user changing a workflow, I would consider it a very bad design, actually a BIG BUG!

-  If power and flexibility of a product means no Governance but just a tool where randomly record "stuff" I stand by my idea of "use pen and paper".

Polemics aside, at present I have this monster that I have to domesticate. I wanted to get an input from anyone and my initial toughts and approach were right.

I see myself working of afternoons and evenings addressing this issue . . . if I will ever been able to fix it or I want it to.

Thank you again for your input Nic.

Comment

Log in or Sign up to comment
TAGS

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