JIRA is a wonderful solution and flexibility is definitely one of its strongest attributes, but with that flexibility comes risk of losing control. JIRA Administrators must always be careful to avoid going down the path of over customization or having too many plugins. In this post, we'll look at examples of requests you might get and explain why should put the brakes on them.
This is the classic scenario which most organizations will encounter at some point. It goes like this: You setup a workflow for bugs, such Open -> In Progress -> In Review -> Closed and everything is fine, for a while. Here comes along Billy, and he'd like something like Open -> Waiting to be Assigned -> In Progress -> Pending Review -> Closed for his team's projects. Now, as far JIRA is concerned, no problem. Since the bugs will be created in separate projects, they can use different workflows.
I would advise against going down that path. Why? Well, what's to prevent another person, Jimmy, from requesting yet another workflow for bugs his team manage? I can guarantee it will happen. Maybe not tomorrow, but you've essentially opened the door, and I'm talking about hangar doors, for everybody to have their own version of the workflow.
If you find yourself in this situation, the first thing you do is say no. Then you organize a meeting with the people who use the current version of the workflow and the people who want their own version. The goal of the meeting is to come up with ONE workflow that will be used for bugs across the entire JIRA instance. Maybe you'll end up with an updated version of the original workflow, and you know what? That's great! So the take home message is: A bug is a bug is bug is a...
Very similar to the previous point, but still very important, because screens and fields are usually perceived as being less complicated than workflows. So Billy will come in and say "Oh, the workflow is fine, I just need this extra field(s) in the creation screen, just for my team". Red Alert! Again, creating a field and adding it to a screen is trivial in JIRA, and the same issue type, like a Bug for instance, can have different screens across projects while still sharing the same workflow (Flexibility). Problem is, you now two sets of screens to manage, and when a new project is added to JIRA, how will you know which screens to give it? Again: A bug is a bug is bug is a... (replace by whatever issue type is being discussed)
As you may know, there are two "categories" of fields in JIRA, so I will address this item in two parts. The first one is about JIRA standard fields, ie the ones that come with JIRA out of the box (Summary, Description, Priority, etc...). What if someone asks to rename the Summary field to Title. First of all, if you're using JIRA Cloud, you can't, so that settles that. If you're on JIRA Server, it can be done, but you'll need to edit a file directly on the server. But from now on, every time you upgrade JIRA, you'll need to apply this modification again. Painful... and you'll probably forget to do it unless you're extremely well organized. To be clear: Never rename a JIRA standard field. Ever. If people insist, tell them no again, and then add: Deal With It. They might not like it at first, but they'll respect you for it.
The second part concerns Custom Fields. Renaming a custom field in JIRA is trivial, but it may set off a chain reaction that will have a huge impact on your users. That's because JIRA Filters, or saved search criteria, reference fields by their name directly, not by their internal id. I know it's crazy, but it is what it is. So what I'm saying is if you rename a JIRA Custom Field, you might very well be breaking several JIRA Filters and therefore several JIRA Dashboards as well. Ouch!
So again, the first thing you should do is say no. If the person really insists, make sure you engage your power users / owners in order to get everybody to agree on the change. When the new name is decided, run this SQL query to determine if there are filters that use the custom field you're about to rename:
select filtername from searchrequest where reqcontent like %field name%
Where fieldname is the name of the field (keep the %). If you're on JIRA Cloud, you'll need to generate an XML export and the XML directly for filters (sorry).
This is a big one. JIRA has a built-in Marketplace that allows you to easily buy and install plugins. Also, all plugins can be tested for free during 30 days, so it's all good right? No! There's all kinds of plugins out there. Some have little impact on JIRA, while others will really alter your JIRA instance. Some are well supported by well established companies, some are developed by one dude in his basement who's just playing around with the tech. Make sure you thoroughly research the plugin, and if you feel it's legit and the price is right (which implies your company is ready to pay that price) then install it on a copy of your production instance. (You don't have a copy of your production JIRA? Create one now!!!)
So when Jimmy asks you to install JIRA Service Desk on the production instance, you say no! Then, out of courtesy, ask him why. If he says "Well I heard it rocks (it does) and I just want to test it", you know he's wasting your time. If he says "Well we're interested in replacing Remedy by JIRA Service Desk, and we've got approval for a pilot project", it's time to spin up that clone of your production instance!
You get will all kinds of requests for JIRA, as a manager or application owner it's very important to put a process in place to govern those changes to avoid all kinds of problems. As a JIRA Administrator, you must learn to take it slow and take the time to understand the implications of what you're about to do, if if it takes 5 minutes to do it.
Jimmy and Billy are totally a Double Dragon reference.