Jonny Carter Expert

You won't be able to provide a dynamic language like that with the Simple Scripted Validator, but you might be able to pull it off with a regular Scripted Validator. Just change the string text in the exception you throw to match the user's language setting. To get your other plugin's i18nHelper object, you may want to…

Rambanam is right. Getting the priority field will return a string with an integer value in it. Also, props for using the boolean syntax of setRequired to its full effect. I might have put the contents in a variable, like: def priorityValue = getFieldByName("priority").getValue() as…

@Arianna Fabbri - If you remove one of those CC fields (either the CC addresses or the CC issue fields), do the notifications go out? If not, that's probably a red herring; those fields should work together normally. I'm assuming the above log sample from a mail that successfully went out, right? Not a failed one?…

That sounds suspiciously like you have a condition on the post function that's causing them not to send. It would also account for the successful execution history, even though no emails go out. What condition clause are you using on the workflow steps that are failing, compared to what you're using where you're…

Do you see any warnings in your logs like with the text "Error sending email" or "No mail server or sending disabled."? Those warnings would happen if sending were disabled for some reason, or there were some trouble adding an item to the mail queue. You might also check your mail queue. Could be the messages are getting…

Also, I'd be curious what else might have changed in your JIRA instance in the past few weeks. If your notification script didn't change, is there anything else that could have caused the issue?

There was a small change in 4.1.3.22 that made it a bit easier to pick users for scripts like Send Custom Email. I'd be surprised if that resolved your issue–if anything, it sounds like there may be something amiss with your mail server configuration–but it's definitely worth a shot.

So, JIRA keeps a separate log for the mail handler. Look for atlassian-jira-outgoing-mail.log in your JIRA home. If JIRA's having trouble sending out the messages for some reason, the errors will likely be in there. Your log statements may not show up in your logs unless you use log.warn or log.error. Alternately, you can…

I'm not sure I fully understand what you're trying to do. I'm assuming that you're creating a scripted macro, I'm just not clear what you're trying to get out of it? Is it the macro's body as HTML, the entire page's HTML, or what?

For the future, it might be good to either update your question or post a new one when you have something like this. Posting a follow-up question as an answer makes for a confusing Q&A thread. As to your issue, some more detail about the problem would be helpful. 1) Could you log some of the critical variables and pieces…

cfValues is only defined for the issue itself. If you're iterating through subtasks, you'll need to use the .getCustomFieldValue method as Vasiliy described.

The Groovy collection method removeAll actually returns a boolean and mutates the original collection. So you'll need to either replace it with a findAll and negate your condition existingValues.findAll{!(it.name in ["Orange", "Green"])} or do the removeAll on a separate line. Don't for get to add the *.id aggregator…

The simplest way to erase the field would be def componentsField = getFieldById(COMPONENTS)componentsField.setFormValue([]) Be forewarned, that will erase all components, including those set by the user and ones you aren't interested in changing. For example, let's say you also had the components Apple and Pie. You…

If you want their full names, you'll want to use the getDisplayName method. import com.atlassian.jira.component.ComponentAccessordef awardNomineesField = ComponentAccessor.getCustomFieldManager().getCustomFieldObjectByName("Award Nominees")if (!awardNomineesField) { return null…

@Steven Behnke - sure, I'll talk. Though maybe you should open your own question with your particular details, so we don't distract from Shagufta's need?

Bummer! Just to clarify, do you have ScriptRunner for Confluence, or just ScriptRunner for JIRA? Because if you've got SR for confluence, I believe you can create a page from a template via the Java API using the CreatePageFromTemplateAction class... don't have an example handy, but I can cook one up if SR for Conf is an…

So, it sounds like you need to do two things when the sub-task is created: 1) Create a new page from a template in Confluence There does appear to be a REST endpoint in Confluence's API that lets you create an instance of a template with a POST request. You can call it using the app link configuration; see the…

A scripted field couldn't get its values as input from a JQL function, since scripted fields show up in places outside of the issue navigator. You could configure a few different scripted fields that got information like the worklogs from the last month, the last three months, etc., and query by them as needed.…

That's probably because the numbers are getting stored as floating point numbers OR as version objects (which are getting coerced to strings like 10.0). You could convert them with normal Groovy/Java casting. //If the custom field is a string value and is actually 10.0, the below should be safe(cfValues['Take Version 1']…

There are ways. On the simpler side, you could plausibly just use a regular expression to validate that the commit message matches to a JIRA issue in some way. If you actually want to pull information from the JIRA instance for your commit hook, you're going to have to use some other means of communication between the two,…

The documentation on pre-receive hooks notes a built-in hook that matches what you're looking for. You'll provide a JQL query that defines what issues are valid, and the script will require that the JIRA issue be present in the branch name or commit message. There's similar (and simpler) built-in merge check that can…

Those hideable field types are a semi-experimental feature of ScriptRunner, and it occurs to me that what you're experiencing may be normal behaviour. Hideable fields marked as hidden by a behaviour can't even be read via the REST API. It would make sense to me that you wouldn't be able to set their value via the UI, as…

setCustomField should work, even on hidden fields. How are you checking the value of the field? That is, how do you read the value of the field once it's hidden to confirm its value isn't getting set. Maybe this is a new question in its own right?

You need to use issue.setCustomFieldValue to set the field's value in a postFunction. Also, use String, not 'string', which isn't a keyword in Java. import com.atlassian.jira.issue.MutableIssueimport com.atlassian.jira.issue.ModifiedValueimport com.atlassian.jira.issue.util.DefaultIssueChangeHolderimport…

Last line might need to be changed to tgtField.updateValue(null, issue, new ModifiedValue(issue.getCustomFieldValue(tgtField),transientVars.comment as String),changeHolder) as 'string' isn't a valid keyword in java/groovy.

As you've probably already noticed, the GroupManager and UserUtil classes don't have method signatures that take an acting user for adding users to groups or removing them from groups. The IssueService.validateUpdate method does, and there are other methods in the Atlassian API that also take an "acting user" parameter. If…

Hey, @Maciej Olszewski. Take a look at the first example on https://scriptrunner.adaptavist.com/latest/jira/recipes/misc/running-a-jql-query.html. That should give you an idea how to get some JQL results and grab the issue object from them. import com.atlassian.jira.component.ComponentAccessorimport…

You bet. See https://scriptrunner.adaptavist.com/latest/jira/#_static_type_checking for a little more info on the static type checker.

That's just a case of the static type checker failing to understand Groovy's duck typing. Since your script declares the u variable using def, the static type checker assumes that it's a java.lang.Object, which is not the type required by the getPropertySet method. That said, it should still work by the power of Groovy.…

I believe you want getPropertySet(u). getProperties() is going to call the default Groovy object method sig with that name.