JamieA Expert

can you explain doesn't work. That should work but issue.statusObject.name is probably better.

Isn't this question the same as the one you are asking? Why do you need the custom field ID? If you need it you can get it from the view custom fields page, or from the db.

Use either `1 as Long` or `1L`, or `new Long(1)`, no quotes in either case.

You need the name of the custom field, not the ID. The name is the name that you see when editing an issue in the UI. If you want to use the ID, change getCustomFieldObjectByName to another method.

Answer updated...

You can use the "preview" function to see what the subject will look like. This is highly recommended before firing off emails.

http://groovy.codehaus.org/api/groovy/text/GStringTemplateEngine.html It's a pain doing it in the subject. You need something like this: Issue ID: ${issue.id}, Custom Field Value: <% out << issue.getCustomFieldValue(componentManager.getCustomFieldManager().getCustomFieldObjectByName("My custom field")) %>

I have never managed to do an XML backup, even with what I think is quite a small instance and Xmx 4Gb. An XML backup is not necessary though, a db backup plus home dir backup is sufficient to restore from if things go wrong.

There are couple of methods discussed here: http://blogs.onresolve.com/2008/08/setting-issue-security-level-by-issue-type/ The code will need to be brought up to date.

This is a different issue from https://answers.atlassian.com/questions/37540418

What version of JIRA and JIRA Agile?

it is fixed, the fix will be in the next version which I guess will be 3.1.4. I'm not sure when exactly... holidays approaching. You will need at least jira 6.3 though to upgrade to that.

The one mentioned above: No signature of method...

This is going to be fixed in the release after next, which should be 3.1.4. When you click on the flag icon it's not getting the right name for the board... but if you modify the board name it should work. If it doesn't, due to that other problem, that also will be fixed in the upcoming version.

I don't think the behaviour has changed. The reporter allows you to select any user in jira, so a user picker makes sense. The assignee shows just the users that have the ASSIGNABLE permission in the project, which is normally less than say 30 or 40, in which case the Select makes sense because it's faster to use. I think…

I recommend using https://marketplace.atlassian.com/plugins/com.quisapps.jira.jss for python. I am going to drop support for everything but groovy in a future release. FWIW, you will need to install the jar but other than that it should work fine.

Something like this: changeHistoryManager.getChangeItemsForField(issue, "status").find {it.toString == "In Progress"}?.getCreated()

This is quite straighforward with the plugin mentioned above. Your script is just: ComponentManager componentManager = ComponentManager.getInstance()def customFieldManager = componentManager.getCustomFieldManager()def customField = customFieldManager.getCustomFieldObjectByName("Delivery…

It seems this is about JUP: https://jamieechlin.atlassian.net/browse/JUP-10 - do you have a workaround?

issuefunction not in hasLinks() if you are using a recent version of script runner.

I would apply it globally, then you can check if that issue already exists. If it doesn't it must be the "create" action: import com.onresolve.jira.groovy.user.FieldBehavioursif (! getUnderlyingIssue()) { /// this is create...}

can you tail the log, then reproduce the error. Then must be a log entry if you get that message.

i posted the link in my first comment

Although reindexing won't fix this issue, so check the logs first.

https://confluence.atlassian.com/jira/where-are-the-application-server-logs-16121981.html Did you reindex after installing ScriptRunner ? Some functions require it.

What is the context where you are running this, eg a post-function? A screenshot of the whole page would help here.

Fast-track only works on the current issue... so it is able to show a list of actions for the appropriate workflow (the one that is being edited). All other things being equal, I would say that 81 is not a valid action for that state in that workflow. Also this doesn't seem that safe - you can link an issue to any other…

Can you post your code (the simplest example that demonstrates the problem) ? Even though the actions may have the same name they will have different action IDs, and that's what it's complaining about.

that's not ScriptRunner, it's JIRA misc workflow extensions IIRC.

can you provide a screenshot of the configuration so we can check the context