Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Celebration

Earn badges and make progress

You're on your way to the next level! Join the Kudos program to earn points and save your progress.

Deleted user Avatar
Deleted user

Level 1: Seed

25 / 150 points

Next: Root

Avatar

1 badge earned

Collect

Participate in fun challenges

Challenges come and go, but your rewards stay with you. Do more to earn more!

Challenges
Coins

Gift kudos to your peers

What goes around comes around! Share the love by gifting kudos to your peers.

Recognition
Ribbon

Rise up in the ranks

Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!

Leaderboard

Come for the products,
stay for the community

The Atlassian Community can help you and your team get more value out of Atlassian products and practices.

Atlassian Community about banner
4,464,125
Community Members
 
Community Events
176
Community Groups

Scripted Field vs Listener - Which is better to use?

Edited

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?

1 answer

1 accepted

0 votes
Answer accepted

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.

Actually, it should do, if you choose the date/time "template" for its output.

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. 

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)

Like Peter-Dave Sheehan likes this

Suggest an answer

Log in or Sign up to answer
TAGS

Atlassian Community Events