Comments
-
That class is not in use in the plugin in 3.x. There are other plugins that use groovy, perhaps it's one of those? Can you verify you get the same behaviour with script runner disabled? How are you using script…
-
Can you provide a lot more information, such as all the versions concerned, ie java, jira, plugin. What options are you using to generate this information. What you do you have perm gen max set to? I've done a work on this before and concluded that there is no issue. Reluctant to do this again. Have you checked answers for…
-
Works for me - perhaps it's the styling of the hr
-
No, it doesn't matter. The IDs changed between one version of jira and the next around that time, I think FieldArea was downcased. Can you paste the bit from the html source that contains that element, so we can check. NB - this is one problem with doing this, you will end up needing to change it quite often.
-
> Thanks, but it doesn't work Yeah, but what I put does work, because I tested it. You don't mention what jira you're on, but that fieldarea stuff is an old version. If it's an element ID then you need a #, ie AJS.$("#customfield_10510FieldArea")
-
It should work, try something like: AJS.$(function () { AJS.$("#summary").closest("div").after("<hr>")}); It's a bit harder in jira5, but you can still do this.
-
the comment is not added to the new event, this is a bug that will be fixed in the next release, please watch https://productsupport.adaptavist.com/browse/SRJIRA-2005
-
oh, good... thanks for letting me know.
-
I think you want a custom listener like this: https://gist.github.com/jechlin/2824046dd7a4ada6bc3eIn my case I configure it by creating a custom listener, and the class is examples.answers.FireACommentOnResolve, which corresponds with the above.The second clause is just for testing, I tested it by putting it both on…
-
Add a script listener, the one you want is called "Fire an event when a condition is true". It should be configured like this: image2015-1-9 13:16:26.png Make sure you only select the Generic Event to listen for or you will wind up in an infinite loop. Something fishy seems to be going on, in that JIRA seems to be firing…
-
The first tip is to use the \{code\} macro, that makes it much easier to read. I don't see any particular problem with this script field, other than some of the variables aren't used. Doesn't it work? Pretty much everything you need should be at https://scriptrunner.adaptavist.com/latest/jira/releases/UpgradingToJira7.html
-
If you want to dynamically change the recipients, you should send it to the value of a user or multiuser custom field, and you set the value of that to a user or list of users. So "To Addresses" is for email addresses, "To Fields" is for using fields to govern the recipients.
-
There's an example of including custom fields here: https://jamieechlin.atlassian.net/wiki/display/GRV/Built-In+Scripts#Built-InScripts-Sendacustomemail TEST-1 looks like an issue key, presuming that's a custom field name it should be ok.
-
https://scriptrunner.adaptavist.com/latest/jira/recipes/workflow/validators/simple-scripted-validators.html#_validating_cascading_selects
-
This is simple enough in itself, but you can just add jira-users to the list of groups automatically assigned to users when they first log in, in the directory config. Wouldn't that work?
-
Take a look at this plugin: https://plugins.atlassian.com/plugins/com.iamhuy.jira.plugin.issue-alternative-assignee - it can help.
-
Could you simplify your question a bit? It's too hard to take on board the text of it alongside the code. Is the issue: > However, if I filter on releaseTrain, those issues don't show up in the results ie you're searching programatically, and don't find issues that you should do for that custom field? If so, is this the…
-
OK, I don't see why that would not work. Certainly works in the latest version. I need the script to reproduce, maybe you are trying to run as anonymous or something.
-
Any log output? What versions? Can you create a small script that exhibits the problem to share?
-
Gawd... this reminds me of sitting through maths lectures. It's hard to follow through what you are saying, but your first task is to write a JQL for some sample values. For the sub-task part of your query, you could use parentsOf("issuetype = RS and DA = somevalue") In the script runner there is a built-in condition which…
-
Looks like a simple scripted validator...? I removed the redundant frames from your stack trace to make it clearer.
-
Possibly you have a condition somewhere that is trying to check the resolution, but you're inadvertently using assignment rather than ==.
-
There is a condition either on the function that creates the subtask, or in the workflow for the subtask (mostly likely on the create action). And that condition code is failing, it must be wrong. Can you look for the condition?
-
You'd need to override my class (which is not that hard). If you wanted to allow the user to choose between all, new and none, the no-progamming solution might be to have a radio button custom field with those options, add the send email function three times, and use a mutually exclusive conditions based on the custom…
-
Sort out your maven installation, or use the atlassian provided one, and just run build.sh|bat. Once that's working then you can build the war file.
-
I would follow the standard vendor branch pattern for the VCS you are using. This will make it easier to merge your changes when new versions of jira are released. I use Mercurial for this purpose which works a lot better than svn, for one because it's fairly good at spotting moved/renamed files. However it can be done…
-
A few weeks. Unfortunately Atlassian are putting the pressure on by announcing these vulns at the same time as releasing 6.2, so more people than would normally are keen to get on the 6.2.0 release. I agree with Norman, I almost never take the .0 version of a new major release.
-
Don't see why that plugin has anything to do with it.
-
There will be something in the log.
-
Nothing works out because the API has changed, so your code needs to change. For the full story see https://developer.atlassian.com/display/JIRADEV/Renamable+Users+in+JIRA+6.0