I'm trying to have caculated fields in JIRA with Script Runner and these calculated field are reindexed for JQL filters. To perform that, I perform all my calculations on a "Scripted Field" which updates an "Integer Field" that needs to be-reindexed.
My code is :
import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.index.IssueIndexManager import com.atlassian.jira.util.ImportUtils IssueIndexManager issueIndexManager = ComponentAccessor.getComponent(IssueIndexManager.class); boolean wasIndexing = ImportUtils.isIndexIssues(); ImportUtils.setIndexIssues(true); issueIndexManager.reIndex(issue); // line which creates the stackoverflow ImportUtils.setIndexIssues(wasIndexing); return 1
But I have a unknown error, with this message:
java.lang.StackOverflowError at net.sourceforge.jtds.jdbc.JtdsStatement.(JtdsStatement.java:159) at net.sourceforge.jtds.jdbc.JtdsPreparedStatement.(JtdsPreparedStatement.java:100) at net.sourceforge.jtds.jdbc.JtdsConnection.prepareStatement(JtdsConnection.java:2492) at org.apache.commons.dbcp.DelegatingConnection.prepareStatement(DelegatingConnection.java:295) at org.apache.commons.dbcp.PoolingDataSource$PoolGuardConnectionWrapper.prepareStatement(PoolingDataSource.java:318) at org.ofbiz.core.entity.jdbc.interceptors.connection.DelegatingConnection.prepareStatement(DelegatingConnection.java:137) at org.ofbiz.core.entity.jdbc.SQLProcessor.prepareStatement(SQLProcessor.java:563) at org.ofbiz.core.entity.GenericDAO.select(GenericDAO.java:621) at org.ofbiz.core.entity.GenericDAO.select(GenericDAO.java:592) at org.ofbiz.core.entity.GenericHelperDAO.findByPrimaryKey(GenericHelperDAO.java:97) at org.ofbiz.core.entity.GenericDelegator.findByPrimaryKey(GenericDelegator.java:611) at org.ofbiz.core.entity.GenericDelegator.findByPrimaryKey(GenericDelegator.java:649) at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findByPrimaryKey(DefaultOfBizDelegator.java:448) at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findByPrimaryKey(DefaultOfBizDelegator.java:440) at com.atlassian.jira.ofbiz.DefaultOfBizDelegator.findById(DefaultOfBizDelegator.java:431) at com.atlassian.jira.ofbiz.WrappingOfBizDelegator.findById(WrappingOfBizDelegator.java:243) at com.atlassian.jira.issue.managers.DefaultIssueManager.getIssue(DefaultIssueManager.java:149) at ...
Is there someone to help us ? Script Runner also advices to use "IssueIndexingService.reIndex(Issue)", how can we use this new feature?
You cannot make any modifications within a calculated field... the only thing you can do is pull information from the current issue, or other issues, or outside of the JIRA environment altogether, and display it.
When JIRA reindxes an issue it gets the value from all custom fields. In your case, that act reindexes the issue, which gets the value from the script field, which reindexes the issue, which... etc. Infinite recursion and stack overflow ensues.
You should not need to reindex the issue at all... I'd take a step back, remove that code, see what is not working, and ask a new question.
If your script fields have a searcher configured you should be able to search on them fine.
I am using
IssueIndexingService issueIndexService = ComponentAccessor.getComponent(IssueIndexingService.class);
to get the index service.
And I have to disagree. There sure is a use for re-indexing an issue.
You are correct that your custom searcher would update the issue, though only on access.
So until someone access the ticket and it updates itself, the index will contain the old values meaning that filter ( dashboards ) that would show this issue on the updated values will not contain that issue until it is re-indexed.
I agree with that but I think your premise that this is a correct use of calculated fields is wrong. Reindexing issues periodically or when some external value may have changed is not very scalable. I'd consider custom JQL functions or some custom report...
I didn't mean in combination of calculated fields, was talking about the service itself.
In our case we do not have calculated fields but plugins that define a custom field and bring their own searcher along.
Keep the wrong use aside, there is no other way to validate permissions on a ticket without a field inheriting userpicker, grouppicker,...
About the JQL functions, we just dropped our plugin as the jql custom function are very bad in performance and with over 100k tickets and also 40k+ users it can literally shutdown jira. So we switched to preparing most use cases by filling custom fields through a plugin that listens to according changes on a ticket and fills them in a worker thread. so we can keep performance about 200 times faster than by using jql.
I have almost the same problematic.
My goal was to reindex issues whose the scripted field value has changed, in order to sort them in the issues viewer.
If you run a groovy script inside the scripted field, it ends in a infinite loop.
Then, I run my groovy script in an escalation service which runs every minute.
I share with you my code which works well under Jira 7.1.0, maybe it can help you.
Escalation service :
To test under script Console, you have to define "issue" before :
Atlassian Summit is an excellent opportunity for in-person support, training, and networking.Learn more
Hi, everyone! Molly here from the Jira Service Desk Product Marketing Team :). In the spirit of this month's august-challenge, we're sourcing stories of Jira Service Desk activation fro...
Connect with like-minded Atlassian users at free events near you!Find a group
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no AUG chapters near you at the moment.Start an AUG
You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs