How to determine Field Type of Scripted Field

[Christian_Schönert]

Hello,

I am running JIRA 7.2.4 and Adaptavist Scriptrunner for JIRA 4.3.15.

While writing a Gadget Plugin, i wanted to place a DateField picker, where you can chose a DateField that shall be used for displaying something. I figured Jira has an already built in REST interface with: /rest/gadget/1.0/dateFields to get all DateFields. The Problem is, that the ScriptedFields have a different CustomFieldType than DateField (CustomGroovyField).

I do have some scripted fields that have date picker as search template where they calculate their dates from other data, so they are basically date fields but they are not derived from DateField.

For now I copied the REST interface and manually add them to the list (by name). Is there a generic way to determine the underlying type of a scripted field, or any other more elegant solution to this problem?

Example:

for (final Field field : navigableFields) {
    if (isDateTypeField(field) || field.getName().equals("Currently planned begin")) {
       fields.add(new DateFieldBean(field.getId(), field.getName()));
    }
}

[miikhy]

Hi,

I would recommend you to use the RegEx groovy feature :)

boolean match = "2010.12.12" ==~ /\d{4}\.\d{2}\.\d{2}/

This would work if your date custom fields are formatted in such a way you can find an associated regular expression. If you are not familiar with regular expressions, internet will help you finding the associated regex to match your needs, a good example is here: http://www.regexlib.com/Search.aspx?k=date

Your script can therefore be updated to check either isDateTypeField or  (CustomGroovyField + matching pattern).

Hope this helps!

[Christian_Schönert]

I had that thought before. The thing is, I need a list of all fields that can hold dates, which means they don't necessarily have content that can be processed through regex checks. That's why I need information about the type as I can't always expect it to have content.

[Nic Brough -Adaptavist-]

There's a slight problem there - the "type" of a scripted field is "a scripted field"

There's nothing ScriptRunner can do about this, and not a lot Jira can either - it's the way Jira has to handle custom field types.

Your only option over REST is to check if the content returned looks like a date.

[Christian_Schönert]

I've come to terms with the fact that Jira has a lot of issues (API-wise) with determining types of fields. But I'll probably do a ticket on that, since there are some parts of it, that seem to have a lot of improvement potential.

To this question, which doesn't seem to have a satisfying answer and for all who suffer the same problems, here's my insights and best approach so far:

Determining a DateField is apparently by far the easiest part. As you can import DateField and check if a field is an instance of DateField. The only fields not available in this context are the ScriptedFields. You will have to handle them manually. But to the manual handling later.

For another Field Selector I needed all NumberFields. So there is no such thing as an equivalent of a DateField. There is only a NumberCFType (NumberCustomFieldType), which you can't naturally import for instance checking. I haven't checked if you can import it as a Component or something, so I had this workaround:

private boolean isNumberTypeField(Field field) {
    if (fieldManager.isCustomField(field)) {
      final CustomFieldType<?, ?> customFieldType = ((CustomField) field).getCustomFieldType();
      return customFieldType.getClass().getSimpleName().equals("NumberCFType");
    }
    return false;
  }

What really twisted my head was that the customFieldType.getName() gives a translated name. So depending on what language the logged in user has, the method gives a different result. So this was the easiest way to have a consistent name given, without the need to translate around.

There is no way I found to determine for the system fields, but afaik there is no number field.

There are also some other interesting types in style of NumberCFType like MultiSelectCFType, ProjectCFType etc.

For all fields that don't fall into those conditions, I didn't want them hardcoded in my java classes, so I created some custom REST interfaces that are extendable. I created a small velocity admin page, where you can manually add and delete fields to this REST interface via ActiveObjects (including all fields that don't already make up the REST result).

For me, that's the most elegant solution I came up with. I am open for better ideas, but so far this topic is through for me. I still consider opening a ticket for this unintuitive Type handling in Jira.

And of course: Checking for content of fields is useless in a general approach, if you want to be able to select fields, even if all their uses are empty.