Just a heads up: On March 24, 2025, starting at 4:30pm CDT / 19:30 UTC, the site will be undergoing scheduled maintenance for a few hours. During this time, the site might be unavailable for a short while. Thanks for your patience.
×When creating a scripted field, I'm pulling information from an external database in my script. It seems relatively simple, and it seems to work once, but then it will never work again. Everything depends on issue.reporterId, but when that reporter changes, my fields don't seem to update. I've tried disabling the cache, but that wouldn't help. Any thoughts on this script or some updates or settings I'm missing?
Also, my logging doesn't appear to work, probably because I'm bad at this!
import groovy.sql.Sql import java.sql.Driver import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.user.util.UserManager enableCache = {-> false} log.info("Disabled Cache") def userManager = ComponentAccessor.getUserManager() // All for the SQL stuff. def driver = Class.forName('com.microsoft.sqlserver.jdbc.SQLServerDriver').newInstance() as Driver def props = new Properties() props.setProperty("user", "xxxxx") props.setProperty("password", "xxxxxxx") def conn = driver.connect("jdbc:sqlserver://SQLBOX:1433;instance=CP;DatabaseName=xxxxxxx", props) def sql = new Sql(conn) log.info("Connected to Database") log.info(issue.reporterId) try { def wow = sql.firstRow("SELECT t.ManagerPartyID, t.Segment AS segment, t.CostCenter AS costcenter, (SELECT s.NetworkLogin from MasterData.NOV.Employee as s WHERE s.PartyID = t.ManagerPartyID) as Manager FROM MasterData.NOV.Employee as t WHERE NetworkLogin = ${issue.reporterId}") return userManager.getUserByKey(wow.Manager) } finally { sql.close() conn.close() }
I've tested the SQL query and these work when querying manually. It's also occurring with fields that don't rely on SQL.
Any input is greatly appreciated!
I suspect the reason you're not getting the logs you expect is because the default logging level for ScriptRunner is warn, so you'll only get WARN and ERROR level logs. You could up it to INFO by running this in the Script Console:
mport org.apache.log4j.Level import org.apache.log4j.Logger Logger.getLogger("com.onresolve.jira.groovy").setLevel(Level.INFO)
Any issue should be automatically reindexed whenever it gets updated; you shouldn't have to run a full reindex to get your Scripted Fields updated.
Nailed it. Thank you!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No prob. Holler if you need anything else!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You may need to check and see what type of "Searcher" is being used for the field. Those Searcher templates are used to tell JIRA what type of field it should be classified as when used for Search Results. This also tells JIRA that it should store the value in JIRA's indexes. If you set the Searcher template to "None", this should keep JIRA from storing it in the Indexes and force the field to re-load on page render.
To make this change, you will need to go to Admin > Issues > Custom Fields, find the field in question and then "Edit" and update the Search Template used.
You may also need to check and make sure that there is no DB caching happening as well.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hmm, still not working as I would expect. It's being cached somewhere, I'm just not sure where, or how i would force reload on view, or even on update.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Did you run the Re-index after updating the Search Template? The new template won't be applied to existing data until the re-index has been run.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
No, our instance takes hours to index fully so I'll need to hold off on it. I reindexed the project for what it's worth.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Speaking of long running re-indexing, how many scripted fields are being used in your JIRA instance? If you have several scripted fields in use, that could be part of the reason that the re-indexing takes so long to run. If you disable ScriptRunner (or at least the ScriptFields module) before you run the re-index, you should see a significant difference in the time it takes to run.
Do you have a test environment that you can use to test any changes mentioned here? Having a test environment would also allow you to set some logging to DEBUG in order to help figure out why something is or isn't happening.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
*how many scripted fields are being used in your JIRA instance?
4
I do have a test environment that I can play with. Is it as simple as setting the following on the custom field script?
import org.apache.log4j.Level import org.apache.log4j.Logger Logger.getLogger( "com.onresolve.jira.groovy" ).setLevel(Level.INFO) |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Possibly. If you go to Admin > System > Logging and Profiling, you can set the system to Debug. This will produce a huge amount of logging to be written, and can seriously degrade performance on a production instance. As long as there's not much traffic in the test environment, you should be able to sift through it. If we wanted to look at setting individual classes to debug, I would definitely find any class that references "Index" and set those to debug. Then go update an issue, verify that the change did not carry through the script, and then start sifting through the logs. There will be a lot of useless info to go through, but it only takes one hit to help unravel the pile. Also, since you've added the Script Logging, can you verify that all of the statements are executing correctly and returning the correct results?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.