Resources["CurrentSessionInfo"].GetCurrentUserLanguage() not working....again

[bbeuckSIG]

Dear Thingworx community,

today we deployed Thingworx 9.3.5 to a productive platform. When testing all features I noticed a bug and after some investigations I am pretty certain this is not a bug on my end but Thingworx.

We have a user dedicated to run internal Services, called twxServiceUser. This user is supposed to use the local language since we print screens and send it via mail. I have checked this multiple times, reset and set the language (through script and manually in Composer), the preference for this user (in the today's case) is "de", as it should be. Also the printouts appear in German language. But when calling the Service 

let langs = Resources["CurrentSessionInfo"].GetCurrentUserLanguage();

by Script I get back an empty string instead of "de". 

So I came here / google and searched for this issue, I might not be the only one. And indeed I found a support case, last change 2019 but referring to a post from 2017: https://www.ptc.com/en/support/article/cs292583

First thing to notice: "Resolved in ThingWorx 8.5"
Well, apparently not? Or did it come back somehow?

Second thing to notice: It suggests a workaround using

var result1 = Users[Username].GetUserPreferenceInfo();

Here it gets tricky because my result is depending on the the calling user. With my admin user I indeed get the result "de". But when the user twxServiceUser itself calls this Service it will return an empty string again. This leads to the assumption of a missing permission maybe?

I have only tested on one system so far and as of now it is reproducible. Not sure if / how long this will last. As said before, we are running Release 9.3.5, I haven't found any remark regarding this topix in any release note, neither of this nor of following versions.

Any idea is welcome. Thank you.

Benny

[jensc]

Hello,

I think we are having similar issues in our 9.3.5 instance, however it seems like it is not for all users.

I have at least one user though that in their profile page the language is set to "fr", but in the mashups they see the default language (which is english).

Since your user is used or internal services, and not for mashups perhaps you haven't seen the same issue as my users are facing.

Since my users are from the business, I can't really use:

let langs = Resources["CurrentSessionInfo"].GetCurrentUserLanguage();

To test if they get an empty string as well, but perhaps you could try your internal service user in mashups and see if the language is correct?

Regards,

Jens

[bbeuckSIG]

Hello @jensc and thanks for your feedback,

apparently I haven't been clear, I do in fact take this user for mashup access as well to generate pdf files. The mashup is displayed correctly in German. The generated pdf file is then sent per mail - with English subject and message.

Also when calling all Services via REST by Postman returns empty strings and thus falls back to default (= English).

My current workaround is setting the language hard coded in the overriden Service.

Thank you

Benny

[Constantine · Accepted solution]

Hello Benny,

There's another way to do it:

Users[user].language;

Also, check if you have sufficient runtime permissions to read this property on the Users collection.

/ Constantine

[jensc]

Hello,

Just wanted to post an update to my comment.

We figured out that the users were missing permissions on the localization tables after upgrading the platform (also using a new server).

Regards,

Jens

[bbeuckSIG]

Hello all,

thanks to all for the feedback. For whatever reason it is working now. I am very certain we had all necessary permissions before, we haven't modified anything in the meantime. I suspect a kind of caching issue or similar.

But since I am not able to reproduce the issue anymore (and because I have been politely asked) I am accepting the suggestion from @Constantine as a solution. In case I encounter this topic again I will come back to this thread.

Thanks again
Benny

[Constantine]

That's one good example where Git-centric development workflow makes much sense. Suppose your sources live in Git, and you code-review all changes and deploy them on ThingWorx environments automatically via CI/CD pipeline. In that case, you'd always know exactly why it started (or stopped) working.

[bbeuckSIG]

Our sources are located in and distributed via git. As I said, we haven't modified anything on the system since my original post. Except for my local override to use hard-coded "de" which I have removed now.