Comments
-
What does: "(String) pmValue " produce? Add some logging for that variable. Basically no user can be found with that key.
-
pmValue in your emample above should actually be an ApplicationUser object (assuming JIRA 7). So the email address would be pmValue.emailAddress
-
Work out what the code is to allow it, then put an exclamation mark on the front to negate it. Eg: ! issueLinkManager.getOutwardLinks(issue.getId()).any {it.issueLinkType.name == "Escalated From"}
-
Hey... I think that guy was trying to make a name for himself as a security researcher or something. But it was fixed around 14 months ago - https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner/versions#b603 - so if you have updated since then there is no issue.
-
I agree with Gabrielle... checkboxes that you must check, just become an, err, box-checking exercise... they become part of muscle memory so soon have no value at all. Another way of accomplishing something similar is auto-adding a task to the PR…
-
You can log in as that user using the script runner plugin (admin -> built in scripts -> switch user) or the jira su plugin. Then make them private, or delete them.
-
No problem. And thanks for your review Tomasz, greatly appreciated
-
Note - in the screenshot it shows free text searcher, but actually I changed it to multi user search in another window, then it worked properly.
-
Does the "log" line show the correct things? I see this problem when passing the wrong type of User, but you seem to be using ApplicationUser, which is correct - depending on the version of JIRA. What version are you using? I am not sure why you are converting from appuser to directory user and back again, why don't you…
-
I think this is more of a problem with the API. The default values appear on the screen when you are creating an issue, but if you use the API to create an issue, even if you provide no value for that field, it doesn't appear to use the default value configured in the field config scheme. Also seems related…
-
I've updated my answer, can you mark it as correct. var tab = "#tab2"; AJS.$("a[href='" + tab + "']").closest("li").hide()
-
Say I want to hide the second tab, this works for me: AJS.$("a[href='#tab2']").closest("li").hide()
-
The above code should hide the link.
-
What is the code that you are using? Not tested but something like this shd work to hide all except the main tab: AJS.$("a[href='#tab2']").closest("li").hide() How do you mean "remains as a href"? The html is always going to be in the source so people can get to it if they really wanted to.
-
Reading between the lines, inline editing is disabled where a behaviour is in play. There are various questions about this on this forum, and bug reports etc.
-
Agreed... also tags are bogus. If questioners use the right tags they will get the attention from the plugin authors.
-
Join on issuestatus.id
-
Yep, points please! Ie mark correct and vote up, thanks.
-
Like this: select p.pkey as parentkey, c.pkey as childkey, c.issuetypefrom issuelink inner join jiraissue p on issuelink.source = p.idinner join jiraissue c on issuelink.destination = c.idinner join issuelinktype t on issuelink.linktype = t.idwhere t.linkname = 'jira_subtask_link'
-
Why don't you just check the action? If it's an action that is invoked by the listener itself, then return. (You may be doing this already, have not read all your code).
-
There's something glitchy about reindexing in a listener, but I thought it was fixed in jira 6. I can't find the particular bug right now. To rule out this problem you could try indexing in a new thread, after a short delay. Basically what might be happening is that you reindex, but when your code is done the original copy…
-
What version of jira?
-
What browser are you using? From memory, jira in IE (8?) doesn't work properly when jira.dev.mode is on. Think it's probably to do with the fact that resource batching is off and IE can only cope with 32 stylesheets. It's possible to work round this but you're better off just getting a proper browser.
-
IIRC, the links are stored in the config.xml file, in the root of the fisheye_inst dir - ie the dir where your indexes and so on are. This is such a critical file and so prone to corruption that we have a cron job that checks it into VCS every one hour, if it's different from its predecessor. I know, horse, stable door,…
-
Hi... maybe. If people are interested in it. I had completely forgotten about that, but it seems like a good idea to me.
-
I think it would be a useful feature for post-functions to have "conditions", notwithstanding the terminology clash. That's why I added them to the built-in scripts. Although you can use proper conditions and lots of workflow actions, that's very hard to maintain. > Beyond that, any help in how to use…
-
Henning beat me to it by 13s... the only thing maybe worth adding to this is to put this function as the first.
-
You can use jira: https://productsupport.adaptavist.com/browse/SRJIRA-1468?jql=fixVersion%20%3D%203.1.4
-
You can find the version from here: https://marketplace.atlassian.com/plugins/com.onresolve.jira.groovy.groovyrunner/versions - then follow the link through to the release notes.
-
You can't do that in a listener, you need to do a proper edit if you want to change values after the transaction has already been committed. You should just a standard script post-function, place it towards the top of the list of post functions, and that should work. Although I don't know what line 1 is supposed to do.