JamieA Expert

If I told you the story of why I had to do this, you'd be surprised I hadn't thought up a much worse name ;-)

Update: I've written a simple plugin to display terms and conditions when an editor is invoked, as in my use case I only need contributors to accept Ts and Cs. This is better than the solution below, as you can't continue editing without accepting, and it doesn't waste screen real estate. Walking the floors I noticed that…

Yes, and yes. Instead of having fisheye index all your repos, it just pulls revisions from subversion or whatever VCS "on-demand".

Not at the moment. Everyone with the admin global permission can run scripts. I'm working out a way that non-admins can use the functionality, but it still remain useful.

All of the applicable custom fields are also copied over by default, however the original issue is available in "transientVars.originalissueobject". I meant to make this easier but somehow I didn't.

The summary will be set to the parent's summary by default, so you can do: issue.summary = issue.summary + " Create Feature Fact Sheet"

Almost no coding should be necessary.

Right, so my answer was basically correct.

jira.home must be pointing to some other home directory. It can be set by system property, or in jira-application.properties... check both of those. Or for a quick check make dbconfig.xml invalid by removing some xml tag, and make sure you get an error about that on startup. The other possibility is that you also have a…

I had the same issue. Jira's default screen mapping maps the Edit Issue operation to the Resolve Issue screen which has a post function of updating the Issue’s status to Resolved. (Atlassian devs, this design is pretty annoying for the user and can cause a lot of problems when someone just wants to correct something…

In vm syntax there is no syntax for it, you just do it like <textarea> a multiline default value </textarea>

ie a block like this: (function(){ ... })(); Meaning, run the code in the block when the page is fully parsed and the DOM is available.

Did you put it in the "on document ready" function as Igor showed?

Did you put it in the "on document ready" function as Igor showed?

How does it fail... have you got a stack trace?

> I have a groovy script which requires a select list custom field to create a new issueWhat is the context for this... validator, behaviour, something else? Can you confirm which plugin you're using to execute the code. ta.

I updated the host plugin, but I think the bug only applied to oracle. How big is your database connection pool? I doubled the size but still getting regular outages.

I have had this consistently too since upgrade to 4.3.1. There is a known issue with the mywork (notifications) plugin, which is exacerbated by the calendar plugin if you have a large user base, but I doubt that's your problem. Anyway, I still have the problem since applying the fix for that. Been with Atlassian support…

Yep, I thought so. Maybe on the wiki for the plugin then, not sure...

Someone else posted an update to this script which they said fixes an issue that sounds similar to yours... didn't test it though.

It is compatible now with 4.4 and 5.0: https://studio.plugins.atlassian.com/wiki/display/JUP/User+Picker+From+Project+Role+-+Issue+Alternative+Assignee?focusedCommentId=66355653#comment-66355653

Sounds like you want the Alternative Assignee plugin: https://plugins.atlassian.com/plugin/details/5063 .

You're just parsing the query there, not actually executing a search. You can get the nth issue like so: import com.atlassian.jira.component.ComponentAccessorimport com.atlassian.jira.issue.search.SearchProviderimport com.atlassian.jira.jql.parser.JqlQueryParserimport com.atlassian.jira.web.bean.PagerFilterdef…

You need to join on customfield and customfieldvalue tables. "Sprint" is just another custom field.

There's no need to mix javascript and groovy, that is just unmaintainable. If you're trying to hide or display fields based on another value just get the other field and call setHidden(true/false).

Either in the db directly or better, use bulk fix resolutions from the script runner plugin.

you can get the users from a group with com.atlassian.jira.security.groups.GroupManager#getUserNamesInGroup(com.atlassian.crowd.embedded.api.Group)

Can you expand on the question a bit? What do you mean "queue", filter results?

Most of your behaviours seem to be around role and group access? That seems to be taking a lot longer than before... nothing within behaviours itself has changed that would have caused this, afaik.

Have you enabled nest groups in your Crowd configuration? Did anything change in the upgrade in terms of LDAP or groups?