JamieA Expert

Try userManager.getUserByKey("appcriticality")

Come on, play the game, at least reference the other issue where I told you to use com.atlassian.jira.user.UserPropertyManager#getPropertySet. You can get UserPropertyManager from ComponentAccessor.

new Timestamp(new Date()) or something.

https://answers.atlassian.com/questions/164789/groovy-post-function-clone-and-set-datepicker-customfield

Your date format looks wrong, you have MM twice. I think you want a java.sql.Timestamp, not a Date.

def customFieldManager = ComponentAccessor.getCustomFieldManager()def field1Vals = issue.getCustomFieldValue(customFieldManager.getCustomFieldObjectByName("First Field")) as List<Option>field1Vals*.value The last line gives you the string values of field 1, eg \["Yes, "No", "Maybe"] Do the same for field two...…

Editing values (default or otherwise) is not a problem because in the database the field value is just a numeric ID (from jira 4.4). When deleting a value it does a query for all issues having that value, then updates all issues to remove it from the issue.

I don't think you need either permission to simply save a filter. Sounds like something is wrong... are you definitely logged in when trying to save the filter? If so you might need to contact support... unless anyone else knows.

What version? I remember fixing some issue like this a while ago.

In theory it's possible with jelly runner, in practice not so much, not unless someone has already written how.

As a possibly safer alternative to the above, you can try the copy custom field values function from the script runner plugin. So you could copy Ref Testcase to "Ref testcase new", verify everything looks OK, delete "Ref Testcase", then rename Ref Testcase New to Ref Testcase. Advantage of this is that you don't need…

There is nothing like this in confluence. Integrate with your corporate LDAP and let that handle these requirements.

Do you even need a behaviour at all? The point of behaviours is it will make the change as users are editing the form, then the user can keep that or change it. If you are just overwriting their choice you should not even show this field on the screen.

As I said, move the logic of the switch statement to a utility class under your script root, and use it from both behaviours and the workflow function.

You're using behaviours API in a workflow function. Your problem is you want some logic to happen to set values in response to whatever. You are using a behaviour script to achieve that. But you also want the same logic when creating issues programatically. So you need a workflow function or listener. To avoid maintaining…

Should be available already... there is a view workflow link on every issue, which will open the diagram in a popup. If you are not seeing that check the "view workflow" permission on your permission scheme... it's safe to add "Anyone" imho.

I'd look at using HttpBuilder, it's a wrapper round the library you are using. Get it working first with curl/wget.

Just write to the logs and ignore the result on the screen. The UI has a hard-coded timeout of 90s or something. Until long-running tasks get into the plugin this is not going to change. But does the system you are talking to really take that long to respond?

You need to look at your permission schemes. The list of possible assignees is taken from the Permission "Assignable User", in your permission scheme. Typically, in there would put the project role "Developers". Then you manage your project roles so that only those people directly involved in the project are in the…

Anything referring to copying compiled classes around is almost certainly out of date, sorry about that.

Could you copy to a bug report at https://jamieechlin.atlassian.net/browse/GRV please?

It would not be an adaptation, but something completely different using the rest api and the RemoteIssueLinkService. However as Zulfadli says I would look to existing plugins as there may be some custom field matching to be done which, although not tricky, is probably time-consuming and boring work. If that plugin only…

This can happen when a query passes validation but throws an error, for instance when a function runs. The error message is incorrect, it should say something like "the query had an error", not "the server could not be contacted". I don't think this is the issue the OP has, sounds like slow fisheye. Is there any other kind…

Don't really understand why the current permissions don't work for you. JIRA Admin: Create projects, modify fields etc System admin: Add/remove plugins etc.

It's pretty much this exact recipe: https://scriptrunner.adaptavist.com/latest/jira/recipes/behaviours/select-list-other.html

You can do the whole thing programatically, although the API changed between 6 and 7, so you need to bear that in mind. Creating CFs is simple (com.atlassian.jira.bc.customfield.CustomFieldService#validateCreate), assigning them to projects/issue types is…

hrm... probably only works in 6+

Let me know your jira version and plugin version, I will double-check if I get a chance.

you could try: https://jamieechlin.atlassian.net/wiki/display/GRV/Scripted+Fields#ScriptedFields-DisplayingScriptFieldsinTransitionScreens- worked for me but I think the last report I had was that it didn't work.

Is it a "view" screen and not an "edit" screen right? Calculated fields only show on view screens.