Hi!
Is there a way to switch the OpenMRS session locale using a web service?
Hi!
Is there a way to switch the OpenMRS session locale using a web service?
After skimming that other thread (and reading my last post), I think the short answer is that this isn’t supported yet, but we should definitely add it. Want to go ahead and add this in the webservices.rest module?
Maybe we want:
POST .../session/locale
to set the session localePOST .../user/locale
(set your own user’s default language)POST .../user/{uuid}/locale
(set a different users’s default language, if you have privileges)Do you need all of these?
Thanks @darius. I would only need:
POST .../session/locale to set the session locale
We think this through a bit more and then yes, we can develop and add it to webservices.rest
Okay, as soon as you want, just create a ticket and implement it. This should surely be supported by the REST API.
Is GET /session/locale
already implemented? And is there a way to get available locales?
With these three – (1) get available locales, (2) get current locale, and (3) set locale – we could finally implement locale setting in our new UIs instead of forcing people to the legacy UI to change locales.
Why introduce the /session/locale
end point? I would think locale
and availableLocales
should be included in the /session
resource
No it’s not. The way to get this now is get the global property using: GET .../systemsetting/locale.allowed.list
I would expect GET .../session/locale
to get the current session locale.
@burke do you have a suggestion for how to expose server configuration settings like “all available locales”? (The only precedent we have for doing anything other than just global properties via the systemsetting
resource is the orderentryconfig resource which I implemented at some point and never asked for permission/feedback about.)
I guess I don’t have a strong opinion about whether one should do:
POST .../session
{ "locale": "en" }
or
POST .../session/locale
{ "value": "en" }
Yes, SessionController
is the one responsible for processing requests for the session
‘resource’.
So that would be the way to set the user locale to ‘en’:
POST .../session
{ "locale": "en" }
@wyclif, how would you envision (1) and (2)? Would this be ok?
GET .../session
{ "locale": "current" }
GET .../session
{ "locale": "all" }
GET …/session
{ "locale": "en", "availableLocales": ["en", "it"] }
Why would you pass the "en"
when trying to get the current locale?
@mksd I think you’re suggesting that we do a GET that includes body content, to get the current locale or list of locales. I don’t like that (and I think Wyclif was confused by that, and he’s suggesting the return from a GET).
FYI right now when I GET the session resource I get
{
"sessionId": "1D3F6177CEAE18B8482D12F793A31E76",
"authenticated": true,
"user": {
"uuid": "45ce6c2e-dd5a-11e6-9d9c-0242ac150002",
"display": "admin",
"username": "",
"systemId": "admin",
"userProperties": {
"loginAttempts": "0"
},
"person": {
"uuid": "24252571-dd5a-11e6-9d9c-0242ac150002",
"display": "Super User",
"links": [
{
"rel": "self",
"uri": "http:\/\/127.0.0.1:8080\/openmrs\/ws\/rest\/v1\/person\/24252571-dd5a-11e6-9d9c-0242ac150002"
}
]
},
"privileges": [
],
"roles": [
{
"uuid": "8d94f852-c2cc-11de-8d13-0010c6dffd0f",
"display": "System Developer",
"links": [
{
"rel": "self",
"uri": "http:\/\/127.0.0.1:8080\/openmrs\/ws\/rest\/v1\/role\/8d94f852-c2cc-11de-8d13-0010c6dffd0f"
}
]
},
{
"uuid": "8d94f280-c2cc-11de-8d13-0010c6dffd0f",
"display": "Provider",
"links": [
{
"rel": "self",
"uri": "http:\/\/127.0.0.1:8080\/openmrs\/ws\/rest\/v1\/role\/8d94f280-c2cc-11de-8d13-0010c6dffd0f"
}
]
}
],
"retired": false,
"links": [
{
"rel": "self",
"uri": "http:\/\/127.0.0.1:8080\/openmrs\/ws\/rest\/v1\/user\/45ce6c2e-dd5a-11e6-9d9c-0242ac150002"
},
{
"rel": "full",
"uri": "http:\/\/127.0.0.1:8080\/openmrs\/ws\/rest\/v1\/user\/45ce6c2e-dd5a-11e6-9d9c-0242ac150002?v=full"
}
],
"resourceVersion": "1.8"
}
}
It would make perfect sense to add the current locale as just one more property here.
I would rather put “get available locales” in some sort of common “get system configuration” endpoint, but I haven’t thought through what it would look like.
@mksd that was the return value as @darius said which would also include the other fields on the session resource.
Ok got it, thanks both. I’ll create the ticket as soon as possible.