JamieA Expert

You just run one query and specify the data that you get. Why don't you tell us what's not working?

I don't get what the problem is. A machine will read that rather quickly.

If you need to validate links added this transition, you will need the method described here: https://scriptrunner.adaptavist.com/latest/jira/recipes/workflow/validators/validate-attachments-links-in-transition.html#_validating_links_added_this_transition

Yeah, tricky one. Maybe a custom field that has a template that uses js to lazily get the value from the web service. Depends if you want to index the returned value or not... also you could do caching on the web service side, but there will still be a lot of requests if you do a full reindex for instance.

As far as I know, no. Not short of examining the current stack which you don't want to do. The idea smells a bit fishy anyway, sounds like you will be too tightly coupled. I would focus on speeding up the scripted field, or using a read-only custom field that is updated through a listener.

If they do please please don't do the marketing/popularity contest, that just got embarrassing last time.

Or you can get issue.getGenericValue() and just iterate through the keys. Sounds like something is a bit wrong in your design though.

yeah should have been && what's the exception?

def vals = cfValues['CascadingSelect'].values()vals || vals.first().optionId == 10020

cfValues['CFF Name'].values()*.optionId == [10617,10600]

What version of jira? Is it really a multiselect, or actually a cascading select?

Are those the option IDs or the values? If they are option IDs you want: cfValues['Firma / Ort']*.optionId.containsAll([10617,10600])

You could leave the old jira running (with local db) and modify urlrewrite.xml. But yes it could be helpful if Atlassian documented the exact steps. In practice though personally I think it's better to take the old jira down.

Run apache on the old server on the same port, then use something like this: ## JIRA continuity<VirtualHost *:80> ServerName server2 Redirect permanent /jira http://server3/jira/</VirtualHost>

It's possible, look at http://confluence.atlassian.com/display/JIRACOM/Automating+JIRA+operations+via+wget Take a look at the first URL. It doesn't work now, you may need to disable XSRF checking.

Yeah I agree. GRV-217

It works, you're not explaining what you need, and you're using incorrect syntax. JIRA provides no mechanism to show an error message when there is an exception in that method, that's what it shows.

Syntax is not right, you need: issueFunction in hasLinks("...") and issueFunction in hasLinks("...") Or use OR if that's what you want.

Sorry, only 5.1+

Oh, perhaps you are hitting a known issue which will be fixed shortly. Can you try disabling the plugin then enabling it, then retrying the query?

can you paste the full query that you are trying... and the version of script runner that you're using

What version are you using? It's only in 2.1-beta-x. You need to use: issueFunction in hasLinks("related by") linkedIssuesOf is a bit more complex, it's for finding the issues linked to issues selected by the subquery.

Also in script runner, see linkedIssuesOf().

There's no other way* - go through the dragon slayer thing first so you know how to do it. However I think Atlassian are working towards bring some of the jira studio things to the firewalled editions, like integrated activity streams and searching. * You could try http://www.appfire.com/products/fireball/intro.jsp if…

my.atlassian.com

FWIW you can renew the one-month eval on the website, up to 5 times, without speaking to anyone. However, I suspect Swarm is a better option for you, particularly if your focus is code reviews and not "repository insight". Something made by Perforce, for Perforce only, is probably going to work better that Fe/Cru. p4 is…

It's quite possible that it really will take all the eval period to index, it just depends on the size and "shape" of your repository. To give some perspective, a full reindex would take several months at my instance, and the caches on disk are over 2 terabytes. You could try filtering out branches, as it's probably slow…

I think this issue is fixed in a more recent version, but you could well be using the most recent version supported on that version of jira.

Also you may be using an old version - I don't see any code on that line. What version?

You need to post the full stack trace, but this looks like some variation on https://jira.atlassian.com/browse/JRA-31458 However it just logs a stack trace, it doesn't actually prevent the event from being launched. Perhaps you have another problem as well. Try disabling webhooks and see what happens.