PD Sheehan Expert

Scripts can be super simple or super complicated. If you don't care that this number will grow forever you can put this is the script exactly as is. Here is an example: But you may want to consider stopping the clock when an issue is closed. In which case you'll have to introduce some more complex logic. Something like:…

I get my day durations like this when I want whole days. def durationMillis = new Date().time - issue.created.time def days= Math.round(durationMillis / 1000 / 60 / 60/ 24) You could also use Math.floor() if you want a day to be counted only after a full 24 hours has passed. Math.round does a simple arithmetic rounding to…

Well, nevermind ... I think I found my issue. If I remove my line to validate the object then the store object works correctly. So, somehow the validateObjectBean must be creating a cached version of the object that the storeObjectBean trips over.

Any chance you actually have 2 identical links between those two issues? Maybe add a line at the top of your "each" block: log.info "Examining issues link with id=$issueLink.id" If you have a different id before each of the successes, that should give you a clue.

Can't really help you since I don't have access to those versions right now... but I can say that with 8.5.1 and the latest scriptrunner in my environment, it all works as expected. You can try your luck at using setDescription

I think the sequence of operation when cloning an issue is: * Start Create Transition* Run Create Validator * Run Create Post Function* Launches the IssueCreatedEvent * Create Issue Link* Launches the IssueLinkCreatedEvent So you might have more luck with a listener that listens to the issueLinkCreated event.

Yes, that's exactly what the snippet I shared does. Except I made a small mistake, the last line should be: currentUser.name in approvedUsers Just specify the username for the users you want to be able to see the option in the array approvedUsers. You could just do currentuser.name == 'user_a' //where user_a is a username…

Hi Kai To get the current user, you would use the JiraAuthenticationContext In a fragment condition, I would write it like this: import com.atlassian.jira.component.ComponentAccessor def currentUser = ComponentAccessor.jiraAuthenticationContext.loggedInUser def approvedUsers = ['admin', 'another-admin'] currentUser in…

One of these should work: if (!selectListValue || selectListValue == "No") if (selectListValue == '' || selectListValue == "No")

My bad... I completely missed that you were working with Cloud. Unfortunately, I know nothing of the capabilities and limitations of scriptrunner in a cloud environment. Especially with regards to listeners. At a quick glance, there doesn't appear to be any login/logout event that can be used in a cloud listener. There is…

Well, the Script Listener tab is where you want to be. * Create a new custom script listener, * select LoginEvent or LogoutEvent in the Events to listen too, * Write a script for what you want to do when that event is detected In my case all I did was write a line of text to the log: Then I tailed the log while logging out…

@Robert Giddings _Adaptavist_ it would be really nice if script edit permission could be granted to a group but only in the context of workflows so that: 1) Only System admin can edit global scripts 2) Other users specified by groups (could be jira-admins or non-admin) can still edit workflow script 

Looks like I am able to detect the logout even if I disable the Logout Redirection from my SAML plugin.

I've been able to trigger some actions on login event. But I am not sure how you would tie in your login event script with the SAML attributes unless you can make some api call back to your saml idp and retrieve those attributes again. However, with SAML SSO (reichert solution) I am not detecting any logout event. If you…

That is expected behavior. Scriptrunner behaviours are only effective in full edit screen. They can't work for in-line edits. To get around that, you have to disable inline edits for those fields. Then, when the user attempts inline edit, the edit screen will pop up. To disable those inline edits, just add those 2 fields…

I do not believe there is any real archive option for Jira Server. This is a datacenter functionality only. What we do is "archive" (big air quotes) at the project level. When a project is no longer used, we apply a special permission scheme that will hide the issues from everyone but administrators. But the issues are…

You were very close... The setFieldOptions needs to set the options using the correct data type. getFieldById(AFFECTED_VERSIONS).setFieldOptions(versions.findAll{it.name in ["Figo","Focus"]}) getFieldById(COMPONENTS).setFieldOptions(components.findAll{it.name in ["Engine", "Gearbox"]})

You get a changeLog with an issueUpdated event because that changelog was needed to generate the Change History data. There is no change history for sprints. That data simply doesn't exist anywhere. But it does seem like the event itself contains both the current and previous version of the sprint entity. So you need to…

Hi NONE is not an actual value for the select list. It's only a place holder when no values are selected. So you can do a simple groovy truthy check like this: import com.atlassian.jira.component.ComponentAccessor import com.atlassian.jira.security.roles.ProjectRoleManager def textField = getFieldById("customfield_22695")…

First, have you confirmed that your status change is not causing the assignee to change via a post function? If so, any way to make that conditional?

This may help you: https://scriptrunner.adaptavist.com/6.5.0-p5/jira/behaviours-api-quickref.html?utm_source=product-help#_getrequesttypename

I don't have JMWE and I'm not familiar with how it implements conditional execution. You'll need to consult their documentation or post a new question in a topic where experts on that tool can help you. I'm more of a scriptrunner/groovy/jira api guy (as evidenced by the post title and tag). But basically, you need the…

What app is providing this functionality? It does not look like scriptrunner.

How are the automated tasks created? Can you share screenshots?

@Priyanka Agrawal I would need a little more info to be able to answer fully. Every case is different. For coding to be effective, one needs to know what's already in place and exactly what's desired. But in general terms, you can either hide the transition with a condition that looks for existing linked issues (optionally…

I'm not a fan of the customFieldObject.updateValue() method in general because I don't think it will appear in the issue history. But in your specific case, I would guess that the value you are setting with this low-level api is being updated by the temporary issue object values (which are not updated after you update the…

Moving issues via scriptrunner or JAVA api is not trivial. Think of all the steps you have to go through when you move an issue manually. All those steps would have to be accounted for in a move script without the opportunities to prompt the users for many critical pieces of information. I haven't seen anyone implementing…

Just sort the attachment collection by created attribute: import com.atlassian.jira.component.ComponentAccessor def im = ComponentAccessor.issueManager def am = ComponentAccessor.attachmentManager def issue = im.getIssueObject('JSP-4736') am.getAttachments(issue).sort{it.created}.last()

The static type checking is normal. It's telling us that it cant' determined what will be returned from issue[insightRoFieldBasedOn] ... so it doesn't know where .name is valid for that returned value. If you don't want this error, you can explicitly put issue.reporter.name or issue.assignee.name As for the actual error, I…

I'll go back to my very first words during this interaction "I haven't tried that but...". This was all based on some educated guesses and assumptions. I use Adaptavist Scriptrunner on my Jira instance every day. My experience with Insight is much more recent, and most scripting I do (even for insight) is executed from…