PD Sheehan Expert

I generally try to stay away from manipulating watchers. Users won't understand why they are watching issues which they've not interacted with or added themselves as watcher. You could use a custom listener "send a custom email" instead. You could either just watch issue create event and check for securityLevel ==…

Try this: if(getActionName() != 'Create'){ return // not the create action, so skip the rest of the behavior } Also, it sometimes helps to examine the type of the issueContext. For new issues, the context is not an actual issue yet. But for all other screen, it's an IssueImpl object. So you can do something like this:…

Try the following instead: cfValues['Digital Initiatives'] && cfValues['Innovation'] If you want each field to report that they are required separately, create 2 separate simple scripted validator, then you can customize the message and field for each. The downside to using only scriptunner simple scripted validator is…

Here is what your full script would look like import com.atlassian.jira.component.ComponentAccessor if(issue.issueType.name == "Invoice"){ def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser def linkedIssues = ComponentAccessor.issueLinkManager.getLinkCollection(issue, currentUser).allIssues return…

Why not take advantage of groovy methods? linkedIssues.count{ linkedIssue -> linkedIssue.issueType.name == "Upsell" && !linkedIssue.resolution.name in (["Declined", "Deprecated"]) }

Try some debug message to see where it goes wrong. Output the value of each date before. Then output the new date after each increment. You will be able to see if you log what's happening and where the logic might fail. But at first glance, the fact that you start with expecting your endDate to be before your startDate…

Assuming you mean non-field properties such as described here ... Try to explore the IssuePropertyService import com.atlassian.jira.bc.issue.properties.IssuePropertyService def issuePropertyService = ComponentAccessor.getComponentOfType(IssuePropertyService.class) issuePropertyService.getPropertiesKeys(null,…

I don't understand the question. Can you rephrase/expand?

To do that, you would have to have to make your rest call twice, once to pre-validate if there is any response, and if so, then make the conversion with the ajaxOptions. Alternatively, don't use the ajaxOptions, make your rest request, verify the response is not null then convert to single select with setFieldOptions…

To get custom field value you must * first, get a custom field object * then get the value from the issue (array of "options) * then collect the value from those options * and finally, join the elements in the array for the email body def customFieldManager = ComponentAccessor.customFieldManager def multiSelectField =…

Did you check that you were not compromised by the same virus listed here: https://community.atlassian.com/t5/Confluence-questions/How-come-my-confluence-installation-was-hacked-by-Kerberods/qaq-p/1054605

I generally ignore static type checking errors. These can help with debugging your code, but they don't automatically mean that your code is bad. I would run it and look at the specific line that's failing by reviewing the logs.

I think you need to be in a role that grants "Browse Project Permission". If you only have Browse Project Permission from global permission and not specifically via a project role, then you will see no results.

I don't have a ready script ... but you'll want to consult * SearchRequestService * SearchRequest * PortalPageService * PortalPage * SharePermissionImpl * SharedEntity * ShareTyp The services can be reached with def searchRequestService = ComponentAccessor.getComponent(SearchRequestService) def portalPageService =…

Since the scripted field are calculated server-side before the web-client receives the issue object, I don't think that what you are asking can be done. No data is ever stored in the db. To load field value asynchronously while the user is working on the issue would need to all happen on the client-side. You may want to…

My pleasure. Be sure to click the accept answer so that others can find it and it will appear as "solved".

Actually, @Fabio Racobaldo _Catworkx_ setting the mapping will not clear the default text. Think of manual changes, if you type some description, then change issue type, the text you typed will still be present in the form. Your second option, or leaving all issue type mapped and clearing or entering the default text based…

The "condition" is used to define where one of the three attributes above (Optional, Writable, Shown). While the server-side script is where you would put more complex conditions and actions such as what was suggested by Antoine.

The com.atlassian.jira.issue.link.IssueLink is what the getDestinationObject method is from. This class is what describes objects that links an issue to other issues. That has nothing to do with the URL. I am not aware of a direct way to get the URL from an issue object. But as far as I know, all Issue URLs are formed by…

I don't use cloud... so a bit of a shot in the dark here base on documentation ... but something along those lines my work: def labels= issue.fields.labels def results = issue.fields.subtasks.collect{ subtask -> def result = put("/rest/api/2/issue/${subtask.key}") .header('Content-Type', 'application/json') .body([ labels:…

Here is a full script that works for me in my environment: import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.issue.index.IssueIndexingService import com.atlassian.jira.util.ImportUtils import com.atlassian.jira.event.type.EventDispatchOption def issue= event.issue def issueManager =…

How about an even simpler (and easier perhaps to expand later) script: def fields = ['11200','16601','16600', '11206'] fields.collect {issue.get("customfield_$it")}.findAll{it != null}.join(' - ') "

To expand on the "scriptrunner" option, here is a post from just yesterday that explains how to do that: https://community.atlassian.com/t5/Marketplace-Apps-questions/Set-default-field-value-to-nothing/qaq-p/1066726

Do you mean the LogFileViewer? I just put this together on the fly in my ScriptRunner console by borrowing from other scripts. But it would be easy to embed into a custom rest endpoint like you suggested and have the logfile and line number limit (perhaps with a hardcoded max) be passed as query parameters. This is what I…

We actually implemented a "resolution code" custom field where I can set a different list of values and default for a different context. That's the field the users use. The actual system resolution field is never visible for most projects and is set/unset by the workflow.

Others have already reported this to Atlassian Support. See https://jira.atlassian.com/browse/JRASERVER-68990 and https://jira.atlassian.com/browse/JRASERVER-68910 Including a workaround in comments.

The release notes page for your target version usually links to the upgrade notes page which in turns links to the upgrade procedure page.

Comparing 2 date fields in JQL is not supported. You can compare a date field against a fixed date or a date function. See the discussion on this similar post and non-native alternatives and options.

You could just use the keyboard shortcut "/" to bring up the search panel and start typing. But if you want to navigate directly to the advanced search/issue navigator, you can just go to https://yourjirasite.atlassian.net/issues/?jql=

No, because the cfValue[] is a construct created by scriptrunner and only in workflows. So there is no way to use that construct in the console or elsewhere. You could create a temporary transition that does nothing (from any state to itself) and only output the value of your checkbox field to the log.