JIRA 4.4.6 - How to modify caching behavior so it get the new ticket number from projects table instead from the cache

[Eva]

So my project used JIRA 4.4.1 and we have this requirement that they want a single counter for all the projects, meaning that 1234 should be unique across all projects. So for 4.4.1, we have put in some trigger in our database to automatically sync the counter across all the projects for any updates or inserts. This somehow is broken when we are forced to upgrade to 4.4.6 due to security alerts.

When we turn the SQL debugging on, we notice that in that release, whenever we create or move the ticket, it grabs the next counter values instead of selecting from the projects table for pcounter - which is what they do in 4.4.1. In our debugging logs, we no longer see the select statement to project table, and thus the cache would reused the numbering from 3 months ago and thus affecting our unique numbering system.

My questions has 2 fold - 1)is there a way we can have the cache to force it to look at the project table for pcounter for next value numbering and 2) is there any work around to meet our project requirements?

I appreicated for any help in advance!

[ConradR · Accepted solution]

This requirement seems like a "nice to have feature" by a customer or management. You should discuss the reasons for this requirement and point out the technical problems. I don't think it's worth it.

If you really want or have to do this, you shouldn't do it by messing around in the DB! The best way is to modify the core code directly.

As a starting point you should have a look at the following lines in IssueCreateFunction.java:

long incCount = ManagerFactory.getProjectManager().getNextId(issue.getProjectObject());
            issue.setKey(issue.getProjectObject().getKey() + "-" + incCount);

But again: Jira is a complex system and often there are dependencies you don't recognise at first sight. And of course code changes in jira-core might limit the ability to upgrade to new versions.

[Michael Stelzner [Communardo]]

Try to convince your customer to use a custom field as Unique ID instead of the issue key.

• no core hacks
• maintainability of the code
• nicer to upgrade

You can use the issue id as Unique ID and display this value as single counter for all projects. You can even put the value next to the issue key to make it more prominent.

[Nic Brough -Adaptavist-]

No. You should NOT have done this in the first place, you should never write to a Jira database while it is running. I'm suprised it hasn't trashed your numbering completely, and I certainly wouldn't recommend re-implementing this, especially as Jira becomes more and more cache-able, RESTful and so-on. But, for your questions

1) You are going to have to amend core code, and possibly quite a lot of it.

2) Number your projects as per Jira's scheme instead, but implement another unique key on top.

If I were you, I'd simply dump the whole idea and just write a custom field that exposes the (always unique and fixed) database ID to the users. Ideally, add another tweak that allows your front end to recognise it and redirect automatically. (e.g. when you spot jira/browse/<number> instead of jira/browse/<project>-<number> then assume the number is the id, look it up and jump to it)

[Ruchi Tandon]

Hey Eva,

You might want to reach out to Atlassian Experts from here:http://www.atlassian.com/resources/experts. They are specialists in implementing requirements like these.