JamieA Expert

oh ok - for event listeners IIRC you need to structure that as a script to use it inline, not a class. So, you should end up with (after cleanup): import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.issue.MutableIssueimport com.atlassian.jira.issue.index.IssueIndexManagerimport…

In this context, there should be no difference. "Not works" - how? Checked the logs?

> does that sound right to you? Yeah, all sounds fine. 3) seems most likely. Is the notification scheme associated with the project? Sorry, I am fishing at last resorts here. If you have done this in a test database you could send it to me and I'd take a look.

Can you try the "condition tester" admin script, using the condition you have in the post script, and the issue that you created that should have fired the condition? Have you checked basic stuff like ensure the workflow draft is published, and that the issue has workflow you expect etc?

Let's deal with one thing at a time. So the fire event thing first... set the log level to DEBUG as per https://studio.plugins.atlassian.com/wiki/display/GRV/Script+Runner#ScriptRunner-Logging, then in your logs you will see "Raising event...", if the condition matched. Have you configured it as a listener or a…

atlassian-jira.log...

As always, first thing to do is check the logs and look for errors.

Hi Justin... If you're just trying to raise an event when an Emergency issue is created, why don't you just use the "fire event when..." script which you can either use as a "script listener", or a workflow post-function. If you use that you just select the event and you condition would be:…

Twitter blocked by many BFOs like mine. But thanks anyway.

it's up, finally.

Thanks for confirming. I'd be spitting feathers by now if I had a paid-for plan.

Yes, I think your answer was spot on, it's important to know how to do things without plugins first. I was only quibbling with the actual method you suggest, not your answer. And yes, the automatic action is recorded in the history.

The problem with Nic's suggestion is that you end up with a multiple maintenance problem with all these only-slightly-different workflows. You could try the fast-track transition built-in script from the script runner plugin. You would create one workflow only, where the starting status is New. Then you use the above to…

OK. I still don't think developers should be committing code directly against a support ticket. For me it should be a different ticket type with a workflow suitable for software development, eg code review, in QA, deployed/released etc.

I would favour tracking the development task separately from the service desk issue. You may not want the user to have visibility on all the fields, not to mention "definition of done" will differ substantially. You could use something like…

Agree with Igor and Andy. Had jira been written from the ground up to have the web UI communicate with the backend through the rest API, like say Nexus, then this would be more viable. As it is the REST api is incomplete and probably not as well tested as the servlets etc. P3 will work well for things like Balsamiq and…

If you have that as the first post-function, I think what you have is sufficient. But as Harry says... check the logs, add some debug.

Bad things happen - https://jira.atlassian.com/browse/JRA-25915.

It's a bit confusing what you mean by 2), taken as a whole it reads: "like to reject merge commits on a branch A unless they are on branch B" Have a look at the docn for getCommitsBetween: it will let you see if a commit is reachable from another, which I think is what you want.

It's not a component, or not a public component. You could try using the latest version of script runner and seeing Working With JIRA Agile.

Didn't you get anywhere with your related question: https://answers.atlassian.com/questions/138844/script-to-check-the-release-date-of-versions ?

project in(AI, HD, CON) AND issuetype in(Bug, Story) AND (status = Closed AND updated <= -5d) OR (status in("In Staging", "Rejected") ) ORDER BY Rank ASC You need to separate your two separate clauses with parentheses. Issuetype was in there twice which is redundant.

I guess there's more to your question than you're including, as I know you are aware of some of the potential solutions for this. I agree with Radu, if you have masses of config create a new db table and keep that there. You could then modify the "fields required" validator from JSU to read this table, and if you use the…

Can you explain more what you mean. Popping up a form doesn't unload the page so no. You can disable using the class I mentioned above.

In a nutshell it works like this. When a page loads all the values of all form inputs are serialised. If you do an action like navigating away from the page, the serialised values are compared with the current values. If they differ you get a dirty form warning. Obviously some methods of navigating away from the page, like…

You should not need to explicitly set the default script root directory... possibly you changed your home directory when upgrading?

Nope.

Leaving aside all the good responses regard process, I wrote a tiny bit about how to use script runner with greenhopper here: https://jamieechlin.atlassian.net/wiki/display/GRV/Miscellaneous+Groovy+Scripts#MiscellaneousGroovyScripts-WorkingwithJIRAAgile(thepluginformerlyknownasGreenhopper) Your code would work with…

There is something weird in your setup... eg: java.lang.NoUSERssDefFoundError: Could not initialize USERss Something is substituting the string USERss for the string "Class" in your log... does that ring any bells?

Have you looked at previous questions and the examples on the wiki? What have you put together so far?