I have a feature I want to add, but see that I could implement this using either the ScriptRunner Scripted Field, or Listener. I am not sure how to determine which would be the better feature to use. This is what I am doing.
For issue type A, B and C, when an issue is updated/created, I want to retrieve the Priority and Created Date. Based on the Priority, I want add a certain number of days to the Created Date, and set the new date in the New Date field. The New Date field is not editable by the users, read only so only on the View Screen.
For example:
- If the Priority is "Critical", I add 2 days to the Created Date, then update the New Date field with that date.
- If the priority value is changed to "High" (Or any other priority value), then the New Date is recalculated and updated.
I have already implemented this using a ScriptRunner Listener and configured the listener to only be for certain projects and issue types and on the Create/Update events. All works perfectly.
However, I believe I can implement the same feature by using a Scripted Field?
My question is, are there any pros/cons with doing it with either Scripted Field or Listener that I should consider before choosing which approach to use to implement this in our production environment?
Ok, so I'd rule out a Behaviour straight away - they act on the front end, and although you could use them to default a date into an enterable field on create or edit, the users would be able to override it, and if they edited the priority it wouldn't update. There are also ways they could edit that Behaviours can't intercept, which again would let them break it.
A listener is a good option because it can catch every change and re-calculate your field if necessary.
But, yes, a scripted field might be an even better answer - it's easier to code for, puts less load on the system and doesn't mean your admins have to think about when it is being triggered or remember to never add it to a create or edit screen.
The only thing I would want to make the choice on is how a read-only date field works on screen for your users. Scripted date/time fields look a little different to standard custom date fields.
Thanks for the input. The users had requested the calculated date field to appear on the right side of the screen under the Created/Updated date fields. If I use a Scripted Date field, I am assuming it would not show up over with the other date fields, is that correct?
BTW, I also know if I use the Listener method, users can also do a Bulk Update and still change the Requested Date field value, even though I don't have it on the Create/Edit forms. I think using a Scripted field will eliminate that back door too.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Actually, it should do, if you choose the date/time "template" for its output.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
I was going to say many of the same things you said @Nic Brough -Adaptavist- .
But I have a question for you.
Why would scripted field be less load on the system?
The way I see it, scripted fields have to be run each time the ticket is viewed, edited, or indexed.
Whereas listener script only runs on issue updated events and if done right, exits early with no transactional load on the system after confirming the priority has not been changed. And the actual heavy load of updating the issue is only put IF the priority isis changed.
I ofter struggle to decide between those two options.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
For anyone else reading this - it's going to be quite technical and dull, you might want to stop reading now ;-)
Listeners have to be triggered by every event, there's an overhead in then reading the event to see if you actually need to do anything (or with more simple code, just doing the calculation again and writing the data away even when it hasn't changed)
Scripted fields aren't a lot different, but there are fewer indexing runs than there are events fired, and they offload some of the work to the client browser on view, further reducing load on the "system" (I should have been clear that it's the server side I was talking about)
However, these are very minor differences, I wouldn't look at them outside a performance tuning piece, and mainly because I learned to code in the days where every CPU cycle counted, I've had "ask the CPU to do the minimum you need" beaten into me... If you're comparing listener with scripted field, make your choice based on 1. what output works best for your humans, 2. minimising what your humans have to think about, and 3. what you're happier to support (and hand over to new admins)
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Just a thought, wouldn't it be possible to use native automation here with smart values? What's the blocker?
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
It might be possible, but the question was about doing it with Scriptrunner
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.