PD Sheehan Expert

Did you try what is suggested in the Docker section of this document? https://confluence.atlassian.com/adminjiraserver/setting-properties-and-options-on-startup-938847831.html

I don't think you can solve this with scriptrunner. I'd recommend using a different attribute (text instead of textarea) to display in your form.

Then change that first line from if(issue.issueType.name != 'Sub-task') return false //never show the transition for non sub-tasks To if(issue.issueType.name != 'Sub-task') return true//alway show the transition for non Sub-tasks

You should be able to use the getEditableFieldLayouts() method to get all your layouts. import com.atlassian.jira.component.ComponentAccessor ComponentAccessor.fieldLayoutManager.editableFieldLayouts.collect{"$it.id: $it.name"}.join('<br>')

Behavious methods run against/witch the form data. While the native jira methods run against/with database data. So when you retrieve the value of the customfield using contextIssue.getCustomFieldValue() you get a "Timestamp" object (that a jira api call from the com.atlassian.jira.issue.Issue class) But the "setFormValue"…

@Matt Doar's suggestion is a good one. But I would also add that it helps to break down complex conditions with early return statements. And remember that you must return true for the transition button to be visible. if(issue.issueType.name != 'Sub-task') return false //never show the transition for non sub0tasks def…

It is a known limitation that extension methods provided by HAPI are not recognized by IDEs. You can see more about it here: https://productsupport.adaptavist.com/browse/SRJIRA-6649

It's true that this would be much easier with HAPI as mentioned by Florian import com.riadalabs.jira.plugins.insight.services.model.ObjectBean def fieldId = 12500 issue.update{ def parentValue = issue.parentObject.getCustomFieldValue(fieldId) setCustomFieldValue(fieldId, parentValue.unique() as ObjectBean[]) } But you…

I don't think the resolution date can be set this way. It's designed to be set automatically when a resolution value is applied. There is a very lengthy discussion here: https://community.atlassian.com/t5/Jira-Software-questions/Scriptrunner-w-Automation-Set-Resolution/qaq-p/2076978

The RESTClient automatically converts the JSON string into an actual object. If you only need to work with the underlying data, it's best to keep it as the object. Then you can easily access various elements. In my example from above, you could do something like this: import groovyx.net.http.RESTClient def url =…

Typically, <JIRA HOME> is in /var. That is where logs, db configs, plugins, cache etc reside. This folder doesn't change when you upgrade Jira. Configurations stored there survive upgrades. <JIRA INSTALLATION> is usually in /opt, this is where the executables live. Any modifications you make to those files will have to be…

Upon doing a bit of testing, I don't think that this is currently supported. You can raise a feature request with adaptavist. In the meantime, I suggest you use behaviours to validate the selection rather than hiding it. Here is a sample script you can add to your "Customer Request Type" in a behaviour with "project/issue…

Sorry, never encountered this type of issue. This goes beyond my expertise. Do other scripts (without rest calls) complete without issues in the console. 

I don't think you can do that with a validator script. But it should be possible with a behaviours validation. The "setError" and "setHelpText" methods accept plain HTML. This has the added bonus of flagging the error immediately upon entry rather than waiting for the user to click submit.

No, you have to put it in the jira installation folder. Not the jira-home. It might be something like /opt/atlassian/jira-software/9.4.5/lib (I'm not familiar with that installation model).

Here is a better example than google (which isn't an api) I don't know why this would just spin on your end. Does your server have outgoing internet access?

I've never tried to manipulate the options in the Customer Request Type field. But if it's possible, it will employe a mechanism similar to this: https://docs.adaptavist.com/sr4js/latest/features/behaviours/behaviours-examples/restricting-issue-types

The original question was talking about an Initialiser script. If you want to react to changes to the customer request type field on the Jira (not portal) side, then you need to add that field to the behaviour configuration and add a server-side script to react to that change and show/hide the fields as necessary.

None of those pom files should be modified even if you have access to them. That might break Jira.

What Ram is talking about is the pom.xml that is part of a brand new plugin that you build with the Atlassian SDK. You can't (or at least shouldn't) modify the pom.xml for Jira itself. If however, you are just looking to use POI as part of your scriptrunner scripts, then it's possible to dynamically include those jar…

In a scriptrunner script (listener, postfunction or job) you can use groovyx.net.http.HTTPBuilder or groovyx.net.http.RESTClient to make post requests to external systems. You will have access to the full response There are almost no limit to what you can do with that.

This works for me in the console, in an environment where POI was never used before. import java.nio.file.Files @Grab('org.apache.poi:poi:5.2.5') import org.apache.poi.ss.usermodel.WorkbookFactory import org.apache.poi.ss.usermodel.Workbook import org.apache.poi.ss.usermodel.Sheet import org.apache.poi.ss.usermodel.Row def…

@Kristian Walker _Adaptavist_ while this question is tagged with "cloud" I was going by the title that indicates DataCenter. Maybe he's exporting the excel from DC and hoping to read some of the data from a Cloud instance, in which case, you are correct that this won't work.

Try to move the import below the grabs

The beauty of groovy ... Just add the following to your script and/or Groovy class, and the necessary components will be downloaded automatically: import org.apache.poi.ss.usermodel.* @Grab('org.apache.poi:poi:5.2.5') @Grab('org.apache.poi:poi-ooxml:5.2.5') If you're curious, the libraries will be saved in the user profile…

Yes, that code can be adapted to iterate over a known list of filter ids instead of getting the ids from the database. Here is what that might look like: import com.atlassian.jira.bc.JiraServiceContextImpl import com.atlassian.jira.bc.filter.SearchRequestService import com.atlassian.jira.component.ComponentAccessor import…

I recently had a similar requirement. I was able to adapt code I found here: https://github.com/dtanner/groovy-excel-reader to extract content from an excel file.

The Organization field will store a list of CustomerOrganization objects. You can combine the list (even if you only expect 1) as comma-separated string. Here is your script, slightly modified: import com.atlassian.jira.component.ComponentAccessor def customFieldManager = ComponentAccessor.customFieldManager def customerCf…

The problem with your original code is that the ChangeHistoryItem "userKey" is not actually the user's key or user's name. It's actually the friendly "user display". You need to fetch the "ChangeHistory" object to know the author of the change. Here is a short script that should work in your Scripted Field: import…

I would not recommend the scripted field approach in this case. A user resolving an issue typically happens only once in the lifetime of the issue. But with a scripted field, the script will have to be executed each time you view or index the issue forever and ever. Scripted fields work best for data that is very dynamic.…