Ode about new release of Scriptrunner 6.56

[#1]

Today, I'd like to thank the Adaptavist development team for releasing 6.56.0.

Inlay hints and Completion features.

Because thanks to this version, now, I hope, we will have people in the team follow simple truths:

1. The same names of custom fields, and even more so the same with system fields.
2. Referring to them in general via ComponentAccessor.getCustomFieldManager().getCustomFieldByName("name") - sometimes leads to problems, for example, if point 1 is not observed, or if someone renames the field.
3. The importance of the data types in your groovy code that are accepted as input.

As proof, I will share the story where exactly these rules were violated and led to the deadlock state of the system.

I will not provide the code, since it is within the framework of the NDA. But I can say that this piece of functionality is actively used for company planning.

After a series of research and manipulations with the installation, all the same, the deadlock detector gave information, but more correctly, the reason was found in the log.

Below is the cherished piece of log.

2022-07-08 03:04:33,579+0300 DeadlockDetection:thread-1 ERROR [c.a.jira.startup.LauncherContextListener] Further troubleshooting information about this issue is available in the KB article at: 
https://confluence.atlassian.com/display/JIRAKB/Deadlock+detected+on+startup+error+in+logfile

And on this note, I would like to revive this ticket JRASERVER-38987  in jira.atlassian.com, maybe it's time for a deadlock detector at least from the administrator's hands all the time? :)

As a preventive measure, I run the following script, you can run in Scrip Console:

// This script investigate the duplicated naming of fields in the Jira
// as waiting that request https://jira.atlassian.com/browse/JRASERVER-61376
// Motivation based on the UX and continuous of mistakes in scripts, add-ons etc.

import com.atlassian.jira.issue.fields.FieldManager
import com.atlassian.jira.component.ComponentAccessor

final FieldManager fieldManager = ComponentAccessor.getFieldManager()
final def fields = fieldManager.getAllAvailableNavigableFields()
def sb = new StringBuilder()

def uniqueFieldNames = []
def output = "Start review fields"
def br = "<br/>\n"
log.debug(output)
sb.append(output + br)
int duplicatedFields = 0
for (field in fields) {
    def name = field.getName().toLowerCase()
    if (!(name in (uniqueFieldNames))) {
        uniqueFieldNames += name
    } else {
        output = "${field.name} field has duplicate name"
        duplicatedFields += 1
        sb.append(output + br)
        log.debug(output)
    }
}

output = "Investigated ${fields.size()} number of fields, where duplicated is ${duplicatedFields}"
sb.append(output + br)
log.debug(output)

return sb.toString()

Seeing like this at the end as a report, Investigated 959 number of fields, where duplicated is 30.

I understand that users cannot normally search, scripts can break, and in general their number is growing :). But I see that the Atlassian ecosystem is working towards reducing risks, and vendors too, which pleases me.

Thanks again to Adaptavist's support and development team of course for your patience and sorry if I was pushy with support tickets.

Cheers, GT

[Jamie Echlin _ScriptRunner - The Adaptavist Group_]

Hey Gonchik,

Thanks for writing that. 

Personally I prefer to follow some of your rules eg 1) don't have duplicate field names, and 2) don't rename them without good reason. 

If you stick to those rules you can reference custom fields by name which makes for easier to understand code.

However, for various reasons some people need to or prefer to reference fields by ID - and this inlay hints feature primarily speaks to them.

We're actively working on the editing experience at the moment across all platforms. We have several interesting things on the horizon that we're looking forward to sharing. And we welcome any feedback on the current editing experience, or what people would like to see.

Thanks again!

jamie