PD Sheehan Expert

There is nothing wrong with the script, but what I asked for is a screenshot of the behaviour configuration page so that I can know for sure where the script is being called from. I do have a question about the script... Why this? summary.setFormValue("${inf}" + ":" + " " + "${currentUser}") And not this…

Can you share a screenshot of your behaviour configuration?

I don't think you need to convert the list of options to a map. But also, the components formfield value method will return an array of ProjectComponentImpl objects. So simply applying "toString()" on it will not give you predictable results. This should be better: import…

Usually ... HttpResponseException: status code: 400, reason phrase: Bad Request ...means that something is wrong with your request. Either something missing in the headers or in the body and the remote endpoint is rejecting it. I would add a log above the RESTClient call to output your body as Json then try the exact same…

Where did you put your behavior script? It should be against the server-side script for the custom field that should trigger an update. But be careful, you don't want future users that edit the issue to cause the summary to be refreshed to that user. So either make sure your script only runs on create or if you want to…

Where did you put your behavior script? It should be against the server-side script for the custom field that should trigger an update. But be careful, you don't want future users that edit the issue to cause the summary to be refreshed to that user. So either make sure your script only runs on create or if you want to…

Yes, this can be achieved with SR behaviours. But it should also be achievable with the Insight custom field configuration (assign iql using placeholder).

@Florian PEREZ _Valiantys Administrator_ Here is how I would rewrite the snippet you shared below... Please note that based on the offerec script logic, I was only seeing 2 fields ever set visible: alert and categorie def opt1 = 'Vulnérabilité' def opt2 = 'Incident' def opt3 = '...' def fieldsConfigs = [ [id:…

Correct, the "Create Issue Link" appears to act as a wrapper between two other user tasks. 1) Create an issue (with access to validators, post function and everything else in the workflow) 2) Create an Issue Link (which doesn't execute any workflow feature). With scriptrunner, you can create a listener that will check for…

Scriptrunner has several main areas of functionality: * Script Listeners - executes on an event trigger * Script Field - executes on an issue view or index for each issue * Behaviours - executes on a screen/form load or update * WebFragments - injects components into the ui * Script Jobs - executes on a schedule (CRON) *…

If you only need to run a script during issue creation, you can do that easily by checking to see if there is an "underlyingIssue". When we are creating an issue, that variable is empty. So add, near the top: //if the is an underlying issue, we're not in in a create screen. Nothing to do if(underlyingIssue) return null

Yes, take a look at com.atlassian.sal.api.net.TrustedRequestFactory Something like this: import com.atlassian.jira.component.ComponentAccessor; import com.atlassian.jira.user.ApplicationUser; import com.atlassian.sal.api.net.Request; import com.atlassian.sal.api.net.TrustedRequest; import…

I'm completely self-thought. But the main resources I use are 1) This site. There are many great examples in various posts. 2) The groovy documentation 3) The jira javadocs (almost everything starts with the component accessor) 4) The scriptrunner documentation 5) The adaptavist library

Ah! Sorry, that was my mistake. I've been working with Assets AQL too much lately. Let's try this: import com.atlassian.jira.bc.issue.search.SearchService import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.web.bean.PagerFilter import com.onresolve.jira.groovy.user.FieldBehaviours import…

Can you review the atlassian-jira.log file for errors at the time that you attempted to update the Claim ID field? Let's try to output some messages on the field to make it easier. Replace the script with: import com.atlassian.jira.bc.issue.search.SearchService import com.atlassian.jira.component.ComponentAccessor import…

Can you share a screenshot of the behaviour configuration page?

"static type checking" is not always fatal. It just means that the code editor can't be sure if it will work. In this case, the following line can retrun a String, an Integer, or a sincel instance of an Option class or an ArrayList of Option class depending on what type the custom field is…

That is exactly what the code I provided in my previous comment does.

I would recommend we simply just adjust the error message based on the status of the found issue: if(searchService.searchCount(currentUser, parseResult.query)){ def issue = searchService.search(currentUser, parseResult.query, PagerFilter.unlimitedFilter).results.first() if(issue.resolution){ field.setError("""$inputValue…

As I said, I think triggering the re-open on the original issue seems like a bad idea. Perhaps the user only made a typo in the custom field and I don't think you should automatically re-open the ticket that matched the typo. A script like this in a behaviour configuration for your project against the unique field's…

The trick with single select custom field is understanding that the getCustomFieldValue will return an object of class "Option". So rather than comparing the option object as a string, it is best to use its "value" property. So instead of " $flaggedCfval " == 'Yes' Try flaggedCfval.value == 'Yes'

Sure, just filter using the "getDisabled()" method of the Option Class def cfA = cfOptions.findAll{ it.value.startsWith('Team -') && !it.disabled}

It usually helps to know which line exactly the syntax error is on. And usually, the error will have some details that can help suggest a solution. But when I copy your snippet, I can see a few errors: 1) you are using the wrong type of quotes around "Fix Version". 2) there is an extra dot after the parens on that same…

@Seda Taş sorry, I don't work with Cloud. 

The dropdown for insight custom field can only display a single attribute. Then, on the issue view, you can display additional attributes in what I usually call for my users, the "object card". So, if you want to show the building and the room in the dropdown, you have to create an attribute that contains those details.…

So it sounds like you are attempting the have the values in that custom field unique across all issues in the project. Is that correct? What type of field if the custom field? I see several aspects to this requirement 1) Behaviour When the user fills in the custom field, create a JQL to search for other tickets matching…

Here is yet another version with more logs. import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.fields.CustomField import com.riadalabs.jira.plugins.insight.channel.external.api.facade.ObjectFacade import…

I looked in the API documentation for any classes that might control the connected tickets data, but no luck. Maybe you can ask Atlassian support directly.

Try this version with a bit more error trapping. Make sure you change the 2 customfFieldId variables to match your custom fields. The script currently contains 14932 and 14930 Watch your logs while it runs and capture any details in there: import com.atlassian.jira.component.ComponentAccessor import…

Insight appears to have some internal listeners that will pick up on the fact that insight custom fields have change and update its internal tracking of the connected tickets. In my experience, you need to trigger an "Issue Updated" event on the ticket with the Insight custom field somewhere in the event changelog. This…