How is an Atlassian employee's reputation calculated?

[MattS]

I was surprised to see a newish Atlassian employee's reputation increase steadily over six months with only 2 answers, no votes and no questions. Is there another factor that is special for Atlassian employees? This question is not about the specific user of course.

~Matt

2015-08-12 01.06.09 pm.png

[Nic Brough -Adaptavist- · Accepted solution]

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.

[patricia_scott_honeywell_com]

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.

[Nic Brough -Adaptavist-]

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

[PD Sheehan]

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. 

[Nic Brough -Adaptavist-]

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)

[George Elshamaa]

Just a thought, wouldn't it be possible to use native automation here with smart values? What's the blocker?

[Nic Brough -Adaptavist-]

It might be possible, but the question was about doing it with Scriptrunner