nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

I'm getting lots of errors on Calculated fields

MSCIProcurement

When I reindex my JIRA 6.0.8 instance, I get a lot of ERRORS like:

getCustomFieldValue called from script: No field with ID or name Date of Detection

I've used the "getCustomFieldValue" functions, but it looks it is actually throwing an exception during the reindex...

Here is an example:

return getCustomFieldValue("Date of Detection")?.format("yyyy-MM");

What is wrong with this code? I've have other more elaborated examples which fail the same.

Accepted answers

All comments

Andrew Wolpers

Have you tried simply using the customfield ID as opposed to the name?

I generally do it this way:

customFieldManager.getCustomFieldObject("customfield_11212");

Also, what are you trying to do here? Sum dates? I'd be interested in seeing your entire scripted field code if possible.

Edgar Garcia

Hi there, thanks for the advise. I would assume that I would have to use getValue(this) to get the issue value.

for the specific example I'm returning the "Date of Detection" with format yyyy-MM

There is another case where I read another date "Incident Open", and mix it with the specified Severity to determine an estimated resolution date.

This also fails, the same, the field cannot be found....

Nic Brough -Adaptavist-

My guess is that your "Date of Detection" field has a context that is limited to certain project/issue types, but your calculated fields are less limited.

You will get this error every time your calculated field tries to access a field that does not exist at all for the issue being indexed.

You can either trap it by wrapping an "if field exists" type statement, or limit your calculated field to the same issue types and projects the date of detection field exists on.

Andrew Wolpers

I'd check out what Nic said below, that's definitely something to take into account if the field can't be found by the scripted or calculated field.

Edgar Garcia

Hi Nic/Andrew, if the field context was the problem, it wouldn't work at all in the UI. The fields work perfectly and show the return data as expected in the UI for each issue they are configure for..

The problem is the searcher, it is not working at all.

BTW, I did try to catch the exception

try {
   def  dateOpen =  getCustomFieldValue("Incident Open")
} catch (Exception ex) {
}

Still the error shows in the logs, looks like it is somethign internal to the "CustomFieldValue" method.

Nic Brough -Adaptavist-

I've only every seen that error when the source data field does not exist for the current issue.

Edgar Garcia

Thinking about it. it may be that the Reindex is trying to run the Scripted Field for every single Issue, and of course not all of them have the "Incident Open" field available...... that may be the problem... still the only alternative is to select no searcher.

Nic Brough -Adaptavist-

Ahh, sorry, yes, that's what I was getting at - it will try to run it for every issue that it's valid for. Removing the searcher is one way to fix it, but limiting the calculated field context to the same issues as the source-data fields are for should also fix it (and retain the ability to search and sort by the calculated fields)

MSCIProcurement

Switching user as I got blocked.

Yes, but here is the deal.... the Fields are actually (all of them) limited to Issue Type Incident and Project X.

Also, the Project X has about 100 issues submitted (all Incidents)

Finally, the log generates 100,000 + ERROR messages when reindexing the instance of 180,000+ issues.... This makes think the problem is that for some reason the context is not being respected, so I the only altearantive is to select no searcher. Any Ideas?

Edgar Garcia

Any clue!?

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

jira-administration