-
Bug
-
Resolution: Fixed
-
Low
-
3.3.0
-
Severity 2 - Major
-
Summary
When the request type is set to a non-latin word, in some cases, the search by "Customer Request Type" returns error. This issue is more like an regression in JSD as it cannot be reproduced in JSD 3.2.x
Environment
- JSD 3.3
- Database encoding/collation settings are configured as recommended
- JIRA and JVM's encoding related properties are set to UTF-8
Steps to Reproduce
- Create a sample Service Desk with the project key = "SITP"
- Change the name of a request type to "Шаблонные сайты"
- Change the name of another request type to "解决 系统问题"
- Open issue navigator and execute the following JQLs :
"Customer Request Type" = "解决 系统问题 (SITP)"
"Customer Request Type" = "Шаблонные сайты (SITP)"
Expected Results
Both JQL get executed without any error.
Actual Results
The first JQL returned correct result :
but the second failed with following error
Notes
On JSD 3.2, when user picks the request type from auto suggestion list, the value is converted into a key :
on JSD 3.3 the value is not converted and it remains as what we see in the suggestion list :
Workaround
Use the following SQL (tested for PostgreSQL) to identify the key of each request type and use it in the JQL instead:
select vp."KEY" || '/' || vpf."KEY" as key, vpf."NAME" from project p inner join "AO_54307E_VIEWPORT" vp on p.id=vp."PROJECT_ID" inner join "AO_54307E_VIEWPORTFORM" vpf on vp."ID"=vpf."VIEWPORT_ID" where p.pname='<project name>';
- was cloned as
-
JSMDC-574 You do not have permission to view this issue
cmao
A bit more follow up here.
I was testing on my Postgres instance, and with the Postgres default locale of C, this did not work, as you described. I did some digging, and discovered that this locale of C only understands ASCII, and is therefore unable to upper or lowercase cyrillic characters.
You can find your current cluster locale, by running the follow command on database
I was able to test by initialising a new database cluster using: initdb --locale=ru_RU.ISO8859-5. You can get a list of the locales on system using "locale -a". I chose the RU ISO locale, as it seems to be the most obvious to support Russian and other characters.
Creating the cluster was detailed https://www.postgresql.org/docs/9.5/static/creating-cluster.html
Once I did this, and started up this database server, when I ran
select lower('Шаблонные сайты');
it actually returned the correct result of "шаблонные сайты"
It seems that the real underlying problem here is that the Postgres collation must be using C locale, or another locale that does not understand how to upper/lower case cyrillic characters and therefore does not do it, meaning the SELECT fails.
In code, we can not do the lowercase of the constant in Java code, and pass the text directly to the database as a lower function, so if the collation does not understand it would essentially be doing a direct EQUALS check, instead of EQUALS_IGNORE_CASE, but in most cases that should return the result you need.
However to fix the issue properly, would require creating a new database cluster in required locale, and restoring data onto that instance.
Regards
Matt
JIRA Service Desk developer
NB: My links are all over the place in regards to Postgres versions, but they worked for my testing, but offcourse you probably should find the correct docs for your version just to be 100% certain