Jonny Carter Expert

It depends a little on which kind of script you want to do it in (Post function, behaviour, etc.), but it should be as simple as import com.atlassian.jira.component.ComponentAccessordef userManager = ComponentAccessor.userManagerdef someUser = userManager.getUserByKey("someone")issue.assignee = someUser to get a specific…

The note about listeners indicates that you can't reliably test a listener on something like an IssueUpdated event. Many conditions rely on things like comparing the current value of a custom field to the value it's being changed to. Those conditions only make sense when the event is firing, not on an issue in stasis. For…

Something like this should do just that: import com.atlassian.confluence.pages.PageManagerimport com.atlassian.confluence.spaces.SpaceManagerimport com.atlassian.sal.api.component.ComponentLocatordef spaceManager = ComponentLocator.getComponent(SpaceManager)def pageManager = ComponentLocator.getComponent(PageManager)String…

You're really close. Basically, you need to do two things: 1) Use the IssueFieldConstants that you imported by calling to the constant ASSIGNEE, rather than "Assignee", which isn't correct. 2) Account for the case where assignee could equal -1, which is the value for the default "Automatic" assignee. import…

Also, there are some known limits for the label field: https://productsupport.adaptavist.com/browse/SRJIRA-1080 If you're trying to set a default value, this won't work in the current release (5.0.1).

A few thoughts: Your first condition seems to read "Issue type should be read-only when the current user is in the Hopkins CTE group." Same thing for priority in the later screenshot. What group is able to edit the field that you would expect to be unable to? Is it Hopkins CTE, or are your expecting something else? On some…

One workaround might be to have one of your JIRA admins add a scripted field that calculates the current date plus the remaining estimate and returns a date. Then you could use dateCompare. The scripted field would have code along the lines of import groovy.time.TimeCategorydef today = new Date()def remainingEstimate =…

So, that script will only allow the wtuscan user to pass the validator. I think you'd want something more like import com.atlassian.jira.component.ComponentAccessordef userManager=ComponentAccessor.getUserManager()!currentUser.equals(userManager.getUserByName("wtuscan")) || cfValues['Some Custom Field'] == 'Yes' That…

What version of JIRA & Tempo are you using? We updated the docs for working with Tempo in 4.3.7 to work with Tempo 8; prior versions should work with Tempo 7.

So, issue linking operations need to be put in the doAfterCreate closure, as described in the docs. So doAfterCreate = { issueLinkManager.getInwardLinks(sourceIssue.getId()).each { lpttdblink -> if (lpttdblink.getIssueLinkType().getName().contains('Traitement BSL')) { def idBSL = lpttdblink.getSourceObject() //used for…

I can see that the driver in question is available in a public maven repo. What if you tried getting the jar file via @Grab? // https://mvnrepository.com/artifact/com.microsoft.sqlserver/sqljdbc4@Grapes( @Grab(group='com.microsoft.sqlserver', module='sqljdbc4', version='4.0'))import…

Hey, Alf. I know you already know this, but for anyone else driving by, this is currently under consideration for entry into the backlog: https://productsupport.adaptavist.com/browse/SRJIRA-2223

This may seem an odd question, but if you're going to let users disable their own CAPTCHA, why not just turn it off? That said, I'm pretty sure that you can use the LoginManager for this. import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.security.login.LoginManagerdef loginManager =…

Hey, Peter. Since you've confirmed that the resource is indeed being loaded (and executed?), I won't go into troubleshooting that. The sisue Daniel linked to, SRJIRA-2107, is similar, though I'm not sure our fix will rectify your issue, since your problem lies with some custom Javascript that you've written. I would say…

For the basic implementation discussed above (showing a banner or warning panel indicating that the page is by some means public) the Script Fragment shown below should work. I used the Web Panel type, since we don't want this buried in a menu. One big caveat is that this script does not check for anonymous access, which…

Unfortunately, Tempo doesn't publish a JavaDoc, so there's not a good place to get their method summaries. The best you can do is point a tool like IntelliJ's decompiler at the tempo jar (you can unzip the downloadable .obr file that is on the marketplace) and see what you can divine that way.

If all that you want to know is whether any time has been spent on an issue, then you shouldn't need the Tempo classes at all. In fact, you may not even need the WorkLogManager. The getTimeSpent() method on the JIRA Issue object should suffice.

Notice the last three lines of the script? That's the return value I used that sums up the timeSpent attribute of each worklog object. You'll need that or something like it to get the timespent as a number, instead of returning the WorklogImpl object itself.

The missing bit from CST's earlier example is that we now need a WorkAttributeValueService as well. Fortunately, the handy-dandy PluginModule annotation can fetch that for us. This is an example of a Scripted Field that gets all worklogs of a particular attribute type (Overtime), and sums them. You can extrapolate how to…

You're right... the script should work. Maybe provide the errors being thrown by the Bug Watchers Notification plugin? That may suggest a workaround.

You just need to put that into one of your script roots directories. By default, there's one in $JIRA_HOME/scripts. Make sure to put it in the appropriate packages based on the package declaration at the top. So, for the linked example, the directory would be $JIRA_HOME/scripts/examples/jsd/.

Got it. In that case, you'll want to go the more general route and use the ComponentAccessor and CustomFieldMananger classes to interact with the data. Instead of the issue.getCustomFieldValue() method that I used, you might could just use issue.get("Reorder Type"), assuming that covers custom fields. I suspect this is…

Many of the conditions for post functions have some handy-dandy variables injected into the binding. I don't see a post function with the name you used, but it might be as simple as: cfValues['Reorder Type']?.value == 'Replace Empty' If the Condition blank has a little question mark next to it, click that to see what's…

I think you just need to do event.issue.key The issue navigation property is really just calling the getIssue method on the IssueEvent object. Likewise getKey on the issue object should get you the key. Take a look at the other methods on the Issue class's JavaDoc. .getSummary() (which Groovy lets you abbreviate to just…

You'll probably need to write a custom scripted JQL function, if what you want is to query for issues whose sprints are in a given time frame. https://scriptrunner.adaptavist.com/latest/jira/jql-functions.html Keep in mind, though, JQL queries return issues. If you want to get the Sprints themselves for some other purpose,…

No prob. Holler if you need anything else!

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.Levelimport…

The class is com.onresolve.scriptrunner.canned.confluence.admin.CopyTree. You can find it in the plugin jar (after unzipping it) under com/onresolve/scriptrunner/canned/confluence/admin/CopyTree.groovy. There are some notes in the JIRA documentation about calling built-in scripts remotely via REST calls and hacking…

So, this is actually a side effect of the fact that the user picker field can't display inactive users. Since the "From" and "To" fields are actually user picker fields, they won't work if a proper user isn't returned from JIRA's built-in user picker REST endpoint. One temporary workaround might be to call the built-in…

Actually, if you have a behaviour associated with a field, it should disable inline editing on the View Issue page. Granted, the user could still cheat with more advanced techniques; disabling inline editing is JavaScript based, and happens shortly after page load. Behaviours are about convenience, not security.