JamieA Expert

It probably wasn't in 2.1.17... IIRC. If you are on jira 6.2 you can upgrade to SR 3... https://jamieechlin.atlassian.net/wiki/display/GRV/Upgrading+to+3.0#Upgradingto3.0-MarketplaceCompatibility-isitcompatiblewithJIRA6.2?

What versions of Script Runner, JIRA, and JIRA Agile do you have?

Where do you see that message? Can you provide the full JQL?

Hi Roger... Thanks for that comment. Unfortunately that would be far from straightforward. When you run aggregateExpression it actually makes two requests to JIRA - one to get the search results (where aggExp is a no-op), and then one to compute the actual expression you want. Some javascript writes the expression output…

https://productsupport.adaptavist.com/browse/SRJIRA-1091 - it's not going to happen. At some point we will add support for dashboard gadgets, which will be the solution here...

You should rethink your requirement, because boards are not associated with particular jira projects. It could be one project, many projects, or just some issues in many projects.

Yeah... I'm wondering if I missed out a "not" somewhere! I was trying to say it's quite difficult to do it properly.

Then your requirements are probably broken. Looking like the previous issue tracker should not be a "must-have".

Or you can move things around with CSS and javascript. There have been plenty of questions about this previously. There is nothing that you could consider easy though.

@Alejo Villarrubia [Adaptavist]'s answer is correct but will get the first issue that is linked in either direction. You probably want to follow one particular link type, in which case you could use: for (IssueLink issueLink : issueLinkManager.getOutwardLinks(issue.getId())) { if (issueLink.getIssueLinkType().name ==…

You've installed it with two different ports I guess, both running on / ? I've never used the windows installer but try looking for server.xml. After changing the context root you will need to change the base URL for the instance too (admin -> general config).

My guess is that the two cookies in play here are overwriting the ones for the other instance. If you use a debugging proxy, eg Fiddler, you can check the cookie path for the JSESSIONID. For an instance running with no context root, it should be something like: Set-Cookie: JSESSIONID=3879A8C3288B5677DFA0B999B23364D6;…

that would work, it's not really a solution though.

It's the same as any of the other examples for commenting on an issue, but you will pass to commentManager.create: issue.parentIssueObject instead of just "issue".

This is a known issue with the plugin and recent versions of jira... probably best just to watch the bug (in the GRV project).

If you @mention someone, doesn't that have pretty much the same affect?

;-)I created an issue for this: https://jamieechlin.atlassian.net/browse/GRV-527

Yeah this is super-nasty and not easy to spot. I changed the constants to this and it worked: public static final String FIELD_LINK_TYPE = 'FIELD_PARENT_ISSUE_LINK_TYPEID' public static final String ISSUE_TYPE = 'FIELD_ISSUETYPE' public static final String PROJECT = 'FIELD_PROJECT' basically the problem is that IssueType…

I'll check this out some time tomorrow... it;s going to be something trivial. It;s just your own canned scripts you are having problems with right? The script/class file is in the correct directory under your scripts dir (ie matching the package)?

6-7? Don't tell me Matthew lost on the tie-break again.

Locking is a little difficult because a user can just close the browser and walk away, the server does not receive an event for this. But what could easily happen is that it could warn you when you commit that you are committing an out of date version. Confluence has both features, it tells you that you are out of date, it…

nope

You can get any previous version from marketplace: https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner/versions

Are you using script runner to create the subtasks? I would put the "clear function" before the "store" function, then the "create subtask" function(s) last.

Thanks for the feedback. The wiki and jira projects are being moved, hence read-only.

If writing your own query this would be a good candidate for hitting the db directly: select * from changeitem where field = 'timeestimate', as there will be relatively few hits. I may add something similar to jql functions in script runner.

Basically you need originalEstimate to support the "changed" operator. The few functions that support this have their previous values in a different index. Unfortunately, it doesn't. So given that it's not in the index, the only way to do it with a jql function is the slow way... ie iterating through all issues and…

You should ask a new question, or maybe just implement your condition as a built-in script, like all the built-in scripts do, then it can take parameters and so on.

If you create a workflow condition module then it will be available to be added to the workflow.

Scripted fields are calculated fields, so can't be edited, so will never appear on a screen. Therefore you can't get the value from behaviours, but you can get it from the java API for the issue. Eg: import com.atlassian.jira.component.ComponentAccessordef customFieldManager = ComponentAccessor.getCustomFieldManager()def…