Hey guys. I know it’s been a couple of weeks. I have been working on a large piece on installing JIRA front-to-back. Or pieces, as it were. That one is becoming a bit bigger than I thought It would be. I have most of the first piece done, but honestly I’m considering breaking it up even further.
So I’d figure I’d put up a quick article here in the meantime. It basically came to me like this: As I’m on an interview, there is one question that will let me know immediately whether a company is new to JIRA or seasoned. That question, simply put, is “What plugins (or Apps) do you like?”
I’ve given interviews to those applying to be a JIRA Admin, and honestly, I didn’t think of this as a question. It’s on my list now, though. (Be warned, suckers!)
Now, I should mention caution here. You should never, *ever*, use a plugin to replace something JIRA can do by default. Yes, they do exist. Also, you should be weary about overloading a JIRA instance with plugins. The more you have, the more memory the JVM will need, and the more system resources you need. And you can (and will) get to a critical point where the system becomes unusable because of too many plugins.
As such, I always recommend testing all plugins for a few weeks in a pre-production environment with as real a data set as your policies will let you have. Also have the requesting party test it to make sure it actually meets their needs. This will usually catch a good bit of problems before they cause production downtime.
However, I figured I’d go through some of my favorite plugins, some of the absolute worst I’ve dealt with, and a few honorable mentions. These are in no particular order, just a list for your consideration
My Favorite Plugins
Automation for JIRA
So, I’m sure everyone is familiar with Scriptrunner, the groovy powered everything plugin. You either love it or you hate it. Well meet it’s easier to use younger brother: Automation for JIRA. This is a tool that uses a code-less, drag and drop style editor to build a script that runs on a specified event. It very much has a “IFTTT” feel to it. It has become my new favorite way to automate subtask creation. And get this, you can set this up per project. I mean, if you trust your project admins enough, you can even train them to use it to create their own use cases. I did say “if”, though.
Pros:
- Code-less
- Configurations can be set up at a per project basis
- can be set up to allow Project Admins to create automations that impact only their projects
- Plenty of ability to use information from the triggering issue
Cons:
- Not as flexible or powerful as Scriptrunner
- It is possible to create automations that bog down the entire instance
- Can be blind to field changes that happen during a transition
Link: Automation for JIRA
Timetracker – Time Tracking and Reporting
So I discovered this one fairly recently. The problem I was trying to solve was this:
We had some customers we were billing per hour. The SoP was to have users enter their time in JIRA. However, we really did lack a good way to report and utilize that data once it was in JIRA. Thus comes in the hero of the Hero of the Hour: Timetracker.
Simply put, this changes how time is entered against tickets, and allows project leads and managers to then pull reports on this data. It even has some dashboard gadgets to have near real-time reporting on time tracking data.
Pros:
- Makes entering time against a ticket or issue really easy.
- Allows reporting on the time data already stored within JIRA
- DASHBOARD GADGETS!!!!
Cons:
- You are going to have to deal with “Police State” claims…
- If you have any change inertia in your org, it may be hard to get people to adopt because “it changes how I do things”.
Link: Timetracker
Scriptrunner
I mentioned it’s little brother before, so now it’s time for the big guy himself. The self-described “Everything” Plugin. Scriptrunner. If you know groovy, and you have an idea, this can do it. I think my favorite use case I’ve seen to date was using this to copy contents from one field to another, per issue, so that we could change a field type within the UI.
Now my Groovy skills….yeah, it’s not my strongest language. I really struggle writing groovy scripts for Scriptrunner. However, even a newb such as myself can find use in the built-in scripts. As an example, we setup a project configured exactly as we wanted it. Default groups assigned, permission, field, and screen schemes all the way we wanted them, etc. Then we’d use the “Copy Project” function within Scriptrunner to copy this “Gold Standard” when we had a request for a new project. Afterwords, we’d have to just take care of any customization related to other 3rd party plugins, and we’d be good to go. Turned a half-day affair into a button press.
Pros:
- If you can code it, it can literally do anything….
- Built-in functionality for those of us who are groovy-impaired
- can schedule tasks to run regularly if needed.
Cons:
- Does allow fairly low level access
- An admin that has no clue what they are doing can do a lot of damage
- Can be tricky to learn.
Link: Scriptrunner
Project Configurator
This is my secret weapon as an Admin. Not only does it allow me to play around with a configuration in test, and only move it to production when it’s ready, but it also allows me to move a project, group of projects, or in some cases even an entire JIRA instance, into another one. And I mean both Issues and Configurations.
I’ve used this one many many times in the past. It is absolutely one of my all time favorite add-ons to JIRA. Now, to be fair, if you are moving a large project, it can take a while. My personal record is a project with 60K issues, which took around 12 hours in total. And that was on top-of-the-line hardware you aren’t likely to find at just any company. But it worked, and that is what really matters.
Pros:
- Move configurations from instance to instance, great for testing changes before installing them in production
- Can move issues with projects, making this invaluable for merging and migrating instances
Cons:
- Migrating issues can be SSSLLLLOOOOOWWWWW…..
- Can be finicky at the best of times, even more so if the JIRA versions don’t match. However, so long as the major variables and settings don’t change, success is repeatable.
Link: Project Configurator
Honorable Mentions
Now, these are still great plugins, but I’ve moved away from them for one of two reasons: Either JIRA has taken up the functionality they served natively, or I found a better plugin for it. They are still great plugins, and I still wholly recommend them.
JIRA Misc Workflow Extentions
Misc Workflow Extensions, as the name implies, allows you to extend what you can do within a workflow. It adds a number of Conditions, Validators, and post functions that let you manipulate the issue in-transition.
My main use-case for it was reassigning an issue on the fly. I’m aware you can now do this with vanilla JIRA. If I’m being honest, I missed that mention in the release notes, but it’s a welcome addition to the built-in functionality. But it did make my use of this plugin…what’s the word? Redundant.
Link: JIRA Misc Workflow Extensions
JSU Automation Suite for JIRA Workflows (Formally Jira Suite Utilities)
Aside from that, my use case was auto-generating sub tasks on issue creation. That being said, it was a bit clunky, with you having to format the creation string *just* right to get it to work. I can now do the same thing with Automation for JIRA with a lot less fussing around. For that reason, that is why this is only an honorable mention
This is another one that can do many things, but I was using it for one feature in particular. I know, maybe not the best practice, but here we are anyways.
Link: JSU Automation Suite for JIRA Workflows
How bad can it be?
These plugins here are ones that when possible, I want to immediately uninstall. This is for a number of reasons, to performance issue in JIRA, to plain violating what a Plugin should be. As with my recommendations, I’ll list what’s great and not-so-great about each of these.
Field Security Plugin for JIRA
On the surface, this one provides a pretty valuable functionality. It gives you the ability to define a scheme, in which you can specify who can see or edit a given field. You can even hide the content in the field from a specific group. No joke, this is among my top asks from Atlassian. So why is it on the naughty list?
Well, to be frank, to do this it has to do more than a mere plugin can do. As such, you are provided a zip file that you install in the JIRA installation directory to replace key files with their own version.
Yes, they modify files in JIRA to do what they need. Now I’ve used this for a number of years (against my will), and only had one issue – when I learned you had to replace those files on an upgrade. The issue, oddly enough, was the Pie Chart gadget stopped working. 
Yeah, that doesn’t make much sense to me, but there we were, Monday after a weekend upgrade, with a line at my desk.
Pros:
- Can help you control sensitive information in JIRA.
- Gives options on a per user or per group basis
- Relatively easy in-service configuration after install.
Cons:
- Hiding information doesn’t really lend itself to an “open” culture…
- Settings do not copy with project configs if you are using Scriptrunner to copy projects.
- Because you are modifying JIRA files, this is not available for JIRA Cloud.
- Modifying files within the install directory can invalidate your support agreement with Atlassian, meaning when you need help the most you may not have it. Did I forget to mention that? Well now you know.
To be fair, on that last point, I’ve never been called out and denied support from Atlassian for running this plugin. That being said, I have been warned about it several times, so figured I’d pass that warning along.
Link: Field Security for JIRA
WBS Gantt-Chart for JIRA
If I am being honest, this plugin is passible. I like the idea of the Work Breakdown System. My gripe with this is just how many fields it creates for you. I know, they need these fields to work, but they don’t check if the fields already exist. This means if you have to uninstall it and reinstall it for some reason, it will create duplicates of these fields, again *for you*…
That being said, it does do what it does well, so that may be an okay trade-off for some.
My recommendation is usually to go with Portfolio for this functionality. It uses the data already in JIRA to create charts for you, without needing to many extra fields. It will even help you with scheduling work and finding the critical path. But to each, their own, so if this is your thing, go for it.
Pros:
- It does what it does well.
- Is a lot more intuitive for end users that Portfolio for JIRA
Cons:
- So many fields…
- Can be slow to load for a large number of issues.
- Did I mention the fields…yeah, this one might just be down to personal preference….But I’m willing to admit that.
Link: WBS Gantt-Chart for JIRA
In reflection…
These, ultimately come down to my own preferences and experiences as an Admin. You may disagree and love some plugins I hate. That’s fine. You may loath some plugins that I absolutely love. That’s also fine. However, I do want this to be a conversation. What plugins do you like? What are your plugin horror stories? Anything humorous happen around a plugin install? Definitely leave your stories down below, I’d love to hear them. So, Until next time, have you updated your JIRA issues today?
The Jira Guy 