Each of us, administrators, once made a mistake that we are ashamed of to this day. Reason? Inexperience, oversight or heroic attempt to meet customer requirements. I managed to collect the statements of several brave admins who decided to share their confessions. Check out what happened and how it could have been avoided.
Mistakes are necessary, thanks to them we learn (hopefully!). So here are some good learning materials 😉
The client wanted to see the percentage progress of individual tasks. Thus, the workflow “In progress 5%”, “In progress 10%”, “In progress 15%” was created… and so on to 100%.
Well… if we only have In Progress status, sometimes it’s hard to tell what state this progress is in. A more advantageous alternative to adding a lot of new statuses (!) is to add one field, for example select list and the appropriate values to choose from. But if the configuration of the project is brought to such a place, then you should rather consider changing its assumptions than wade into a dead end.
Well, for example, when I was learning to write plugins, I made a window with a button with the same id as it turned out “Create” when creating tasks. I wanted to block my button with JavaScript and it turned out that no one in the entire organization could create a task because the Create button was inactive :D.
The first thing – testing in production. This would not have happened if the test instance was in use. Regardless of the ID of the Create button (and it is create-issue-submit), to avoid repetitions, it is worth adding a unique prefix, e.g. custom_ then we’ll get custom_create-issue-submit.
Our test environment is weaker than production. We once tested a new version of the plugin and it turned out that a restart of Jira was needed. I was surprised to see how quickly it turns off. I even said to a friend who watched everything via Teams: “Look how nice it is running today, did they add more resources or something?” Suddenly a phone call from the submitter: – Heey, are you doing something with the production environment? It was Friday. 1:00 p.m. :-D
In this case, I think it`s the matter of routine and muscle memory. And Friday;) But seriously, the test instance should have completely different colors than the production one. Same server terminal – different colors and different motd (message of the day).
I changed the names of the statuses on the workflow and then I was surprised that the same statuses changed the names on other projects… then to unscrew it, the whole team clicked for half a day 🤪
Unfortunately, this is how it works – status names are unique in Jira. A change in one workflow applies to all that use that status. Jira warns against this (I don’t know how it was in earlier versions), but in my opinion such a change should only be possible from the level of the status page (jiraurl/secure/admin/ViewStatuses.jspa). Additionally, there is no way to check (or at least I haven’t found) the previous names of statuses that were changed…
The client had two Jira on the host and I upgraded… the another one. In addition, the new version no longer had a valid license, and the database backup was faulty, so a rollback was out of the question. But finally we managed to get along to leave it as it is and upload a trial license.
Overall – a disaster. Several things happened there. First of all, the Jira installer could point to the installation directory of another Jira instance by default (how could it know). The problem with the backup is a separate topic that should be addressed immediately after such an upgrade. The rest is a matter of communication and goodwill. If there were also plans to upgrade and renew the license for this instance, it was simply done earlier.
Do you have similar stories that you want to share? You`re welcome! 🙂
(Photo by Nicola Barts)