By specifying as ‘alias’ the name of an existing action (in actions.xml), you can override default JIRA behaviour.

I first read that line in our docs more than a year ago, and have seen it many times since, but I never really understood how powerful this actually was. When I was writing my Voters and Watchers plugin last week, I hit a wall because our issues are not re-indexed when they were voted on. We did this is by design, because if you can’t search on Voters then why waste time updating the search index when they change.
Unfortunately, searching on voters was exactly what my plugin needed to do. So even after I got the custom field and the searcher working, the search wouldn’t stay in sync with the true state of the issue.
But there seemed to be a fairly easy soluton — I just needed to manually call re-index on the issue (ManagerFactory.getIndexManager().reIndex(issue);, by the way) every time the votes were changed. So I dropped that line into the appropriate place in the Vote action in JIRA and everything started working like a charm. But since I was writing this as a plugin and the plugin wasn’t allowed to modify the JIRA source code. Or was it? That’s when I remember this aliasing idea.
In my plugin, I created a new webwork action (ViewIssueAlias), and gave it the same alias as the ViewIssue action which currently handles voting. I made my new class extend the original one, and overrode the execute() method that performed the vote changes — keeping exactly the same functionality as before, but adding in my re-index step.
One short compile/deploy/test later, my votes were updating properly, my index was staying in sync, and my search was finding the right issues. It’s a little bit hacky, but if it hadn’t been for this aliasing ability, I would have been completely stuck. It proved to me just how valuable that this technique is. I hope that you’ll be able to find a use for it as well.

Fresh ideas, announcements, and inspiration for your team, delivered weekly.

Subscribe now