It is actually a follow-up post. A follow-up to the question Mizan asked in my last post. Before you proceed, here is warning: Strictly for AJS novices, like me!
In this post, we are looking to prepopulate jira fields based on the current user's group. And we are gonna use AJS for the same!
I love football, aka soccer! I was never a good player but whenever I played, I played center back. That is probably one reason why I was delighted when Ken Olofsen announced the JIRA Best X1 of 2011 in this post!
There it was, at No 4 position, my own book alongside a few other gems! A position which was graced by Patrick Vieira to Cesc Fàbregas to Javier Zanetti to err... I would rather not say it ;)
Agile advocate in the room is screaming! How can you have 2 fix versions for a single ticket? How? How? How?
Several scenes (and days) later, Scene N:
Q: We need to restrict the fixVersion(s) field to have only one version. And we need it before the next meeting. Can you?
A: Yup, you are not the first one to ask. Let's do it!
I admit, It's been months since the last post. We have got suggestions on new posts, enquiries about why there aren't any new posts and there was a lot of activity going on in the existing posts. But where exactly have I been hiding?
A book! That's right. I was writing a book! The response on this blog was fantastic and people were asking for more. There wasn't a better option than to publish more tutorials like this in the form of a book. And luckily, this suggestion came from one of the premier publishers in the world - Packt.
Often we come across scenarios where we need to add a new link in JIRA under various places in the user interface. The first thing that comes to mind is "Oh I need to modify the jsps and that means my upgrades are going to be a nightmare"! But hang on, JIRA is far better than you think!
Adding a link is JIRA can be achieved pretty easily by writing a web-section and/or web-item plugin module. And that doesn't involve writing any programming languages, including JAVA.
Ever thought of running scheduled tasks within JIRA? Why do we need scheduled tasks when we have the JIRA Services? We have seen how to write a service in one of the previous posts. But in spite of all its advantages discussed there, services have a disadvantage. It always starts when JIRA is restarted and runs at regular intervals after that. So if you have a service that do some heavy memory intensive operation and if you restart JIRA in the middle of the day, you will suddenly find your instance's performance compromised! If it is scheduled to run every 24 hours, you will find the same service running in the middle of the day from then on until the next restart.
Scheduled tasks in JIRA are a good way to make sure all such operations happen at quite times, midnight for example. In this post we will write a real simple scheduled tasks and see how easy that can be!
In the previous post we have seen how to write a gadget with static content. In this one, we will have a look at creating a gadget with dynamic content or the data that is coming from the JIRA server.
JIRA uses REST services to communicate between the gadgets and the server. We will see how to write REST services in the coming chapters. In this recipe, we will use an existing REST service.
Gadgets are a big leap in the JIRA reporting feature! The fact that JIRA is now an OpenSocial container lets its user add useful Gadgets, both JIRA's own and third-party, into its dashboard. At the same time gadgets written for JIRA can be added in other containers like iGoogle, Gmail etc!
Let us have a look at writing a very simple gadget, one that says 'Hello from JTricks'. By keeping the content simple, it will let us concentrate more on writing the gadget!
Ever wondered how to enforce permission checks based on workflow status? JIRA gives us a big set of options to restrict many of the operations (like edit, comment etc) on the issue or its subtasks depending on the issue status.
Yes, I am talking about JIRA Workflow Properties.
It is sometimes amazing to realize how we missed something so simple! To realize how a little documentation could have saved us few hours (or days for that matter!). Presenting one that I came across while playing cat and mouse with JQL (JIRA query language).
Here is the scenario: I have a SearchRequest object from which I need to get the JQL query String. That's it. Simple, straight forward. Or so I thought!