Strange behaviour finding custom field by name after upgrading JIRA 6.2.7 - 7.11.2

Question

Hi community,

I ask for help as I am really confused: upgrading my JIRA from 6.2.7 to 7.11.2 core (exactly 6.2.7 -> 7.0.11 -> 7.11.2) ,I stumbled over a strange behaviour in one of my workflows.

After puzzling around a while I discovered, that obviously a condition failed (I am very convinced that it worked back in 6.2.7 ... but I can't swear). The reason seems to be, that getCustomFieldObjectByName("VoD AL/AW Art") of CustomFieldManager returns null. But: getCustomFieldObjectByName("AL/AW Art") returns the field.

That's strange, as if I look at  the custom field, it has the name "VoD AL/AW Art". In jql queries, the field is listed as "VoD AL/AW Art" (and it works as "VoD AL/AW Art", but not as "AL/AW Art").

The only place, where I can find it called "AL/AW Art" is the german translation of the custom field name ... oh, yes, and if I request the field info via REST (/rest/api/2/field) the field is listed as { "name": "AL/AW Art" ... "clauseNames":[ "customfield_15205", "VoD AL/AW Art" ] ...} ... ?

Is it possible, that - long long ago - the field was created as "AL/AW Art" and was later renamed to "VoD AL/AW Art" (providing the original field name as translation for mostly german users)?

But then - why did it work prior to the migration (remember: at least I am convinced it was so)

Maybe one of you out there can shed a light on it?

Thank You,
Alex

Gonchik Tsymzhitov · Answer

Hi @alexander_eller ,

please, try to reproduce with different language parameters on your profile,

{base_url}/secure/ViewProfile.jspa

looks like the cause is the language preferences

Cheers,

Gonchik Tsymzhitov

alexander_eller · Answer

Hi Gonchik, in the DB the customfield table is id 15205 customfieldtypekey com.atlassian.jira.plugin.system.customfieldtypes:select customfieldsearcherkey com.atlassian.jira.plugin.system.customfieldtypes:multiselectsearcher cfname VoD AL/AW Art description defaultvalue fieldtype Project issuetype cfkey and in the translation info queried with select pe.PROPERTY_KEY, ps.PROPERTYVALUE from CUSTOMFIELD cf join PROPERTYENTRY pe on pe.ENTITY_NAME='CustomField' and pe.ENTITY_ID=cf.ID join PROPERTYSTRING ps on pe.ID = ps.ID where cf.CFNAME='VoD AL/AW Art'; I get property_key jira.translation.custom.fieldcustomfield_15205.name.de_DE propertyvalue AL/AW Art which makes complete sense and is consistent. In contrast the result of the REST-field-Query is { "id":"customfield_15205", "name":"AL/AW Art", "custom":true, "orderable":true, "navigable":true, "searchable":true, "clauseNames":[ "cf[15205]", "VoD AL/AW Art" ], "schema": { "type":"option","custom":"com.atlassian.jira.plugin.system.customfieldtypes:select","customId":15205 } } so here the name is "AL/AW Art" while in the DB the cfname is "VoD AL/AW Art" … That's weired …. so I think I have to "swallow the pill" and change my workflow post function conditions to use "AL/AW Art" instead of "VoD AL/AW Art" … but I still don't understand it, why it worked in 6.2.7 and doesn't work in 7.11.2 (You remember, I am convinced it worked ;-) ... Oh, and yes, I alreade re-indexed the issues … Alex

Gonchik Tsymzhitov · Answer

Hi!

what info located in DB in customfield table  exactly?

I hope the better to start from DB info and then check translation info in DB as well :)

Hope it helps