I'm completely stuck here and need your valuable assistance to move further. the problem is, I have a scripted field in number searcher format which works fine. but I'm copying the field value to another number custom field during workflow transition using post-function which is failing in sorting
My wired assumption is script field is storing number object though I return integer value and the same object is being copied to number field which is causing sorting failures.
Any thoughts/leads would be really helpful for me come out of this issue
Thanks in advance
We have encountered this situation and usually we use a scripted groovy or SIL Script to parse information from customfield that are of different type.
Power Scripts: https://marketplace.atlassian.com/apps/43318/power-scripts-jira-workflow-automation?hosting=datacenter&tab=overview (If you are stuck their support is amazing and will help you with any scripts)
Bringing in the response I posted in slack...
Scripted field don't store anything in the database.
The script is executed every time the data is accessed and the render template is applied just for the html display.
The searcher is used when the issue is indexed to determine the format to put in the lucene index and determine how JQL syntax will interpret that field.
I can only guess that when using JMWE for copying the field, it will get the raw value from the script output.
That script output may not match the template or searcher you selected. For example, the script output may be "1" (as a String) rather than 1 (as an Integer).
And JMWE won't care, it will just take the returned value and try to plop it in the other field. It might attempt some conversion.
I would double-check the data type output of the script... and after the copy, double-check the data type output of the other custom field. And then compare and contrast against another instance where the custom number field was populated manually.
Maybe try to replace the JMWE copy function with a scriptrunner function?
Also, are you sure the copy is taking place before the indexing? What happens if you force a re-index? Does the sorting get fixed?
It was not a Scriprunner, JMWE or value stored issue. rather it was field configuration corruption. though my field was set to "Number Searcher" it was not working properly for some reason. I changed the format and flap it back again to original to fix the issue
Thanks & Regards,
Hi @Leo ,
are you using a JMWE post-function to copy the value of the ScriptRunner scripted field to some other field (a standard Number custom field)? If so, JMWE will take the value directly from ScriptRunner - the searcher is not involved in any way at that point - and store it in the Number custom field, just like if a user was manually copying the value on the Issue View screen. And there is no conversion required, as the Scripted Field returns a Double, and Jira's Number custom fields expect a Double.
If you put the JMWE post-function _before_ the "Re-index an issue to keep indexes in sync with the database." post-function, then Jira will then include the new value of that Number field in its index for the issue.
What kind of "sorting failure" are you experiencing? And if you manually input data in the Number field, is it sorted accurately? And which search template have you configured for the Number custom field?
Thanks @David Fischer _Appfire_,
yeah, I'm using JMWE post-function. Jira is not soring issues neither in asc nor in desc of the custom field. I placed this on top of re-index post-function.
I tried manual re-index as well but no luck. let me check more and see what I can do
Jira is a great tool to use across different departments. Forget that paperwork – switch to Jira and get that tasks done smoothly. Marketing Jira allows for a complete digital transformation of you...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events