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

[alexander_eller]

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]

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]

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              <none>
defaultvalue             <none>
fieldtype                <none>
Project                  <none>
issuetype                <none>
cfkey                    <none>

 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]

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