Bug 1501098
| Summary: | Service UI not taking 'user default' language | |||
|---|---|---|---|---|
| Product: | Red Hat CloudForms Management Engine | Reporter: | Vatsal Parekh <vparekh> | |
| Component: | UI - Service | Assignee: | Oleg Barenboim <obarenbo> | |
| Status: | CLOSED ERRATA | QA Contact: | Shveta <sshveta> | |
| Severity: | medium | Docs Contact: | ||
| Priority: | high | |||
| Version: | 5.9.0 | CC: | hkataria, jhardy, lavenel, mpovolny, nansari, obarenbo, simaishi, smallamp, sshveta | |
| Target Milestone: | GA | |||
| Target Release: | 5.10.0 | |||
| Hardware: | Unspecified | |||
| OS: | Unspecified | |||
| Whiteboard: | ||||
| Fixed In Version: | 5.10.0.0 | Doc Type: | If docs needed, set a value | |
| Doc Text: | Story Points: | --- | ||
| Clone Of: | ||||
| : | 1553477 (view as bug list) | Environment: | ||
| Last Closed: | 2019-02-07 23:02:54 UTC | Type: | Bug | |
| Regression: | --- | Mount Type: | --- | |
| Documentation: | --- | CRM: | ||
| Verified Versions: | Category: | --- | ||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | ||
| Cloudforms Team: | --- | Target Upstream Version: | ||
| Embargoed: | ||||
| Bug Depends On: | ||||
| Bug Blocks: | 1553477 | |||
|
Description
Vatsal Parekh
2017-10-12 06:23:25 UTC
In OPS-UI, it's possible to configure i18n on user level and on server (i.e. appliance) level. For user, you can either set the language explicitly, or set global default, which defaults to the server (i.e. appliance) settings. On the appliance level, you can either set the language explicitly, or default to browser defaults. The fact, that OPS UI won't honor the language selection from the login screen is either problem of the API (which might not be sending the correct info, which I doubt) or Service UI. Also, it could be, that Service UI simply doesn't / isn't supposed to reflect the settings made in OPS UI. Nevertheless, this is not a problem in OPS UI, and lack of some settings in Service UI has nothing to do with this (unlike comment #2 suggests). I really wish this was an SUI issue, then I could apply the swift fix! Sadly it is not. SUI does this call `GET http://localhost:3000/api?attributes=authorization` to get the all the pertinent deets about the user, in that response we rely on the value `response.ui_service.display.locale` to set the display language. This value remains unchanged when the Default Locale in the OPS is updated. I logged into OPS, changed the default language, logged out, logged into SUI and checked, still being supplied `en`. Also checked the other spot this might have been set, `response.settings.locale` annnnnnnnd its also `en`. (Note, query above was run on an http client as to completely bypass SUI metaling) After playing around with this setting, I see that the service ui language setting is different than that in the Classic UI. In order to set the language for the Service UI, you can set it upon login or from the User menu in the top right corner of the SUI --> Switch Language. I have verified that the API endpoint Allen mentioned above, `/api?attributes=authorization` response.ui_service.display.locale gets updated accordingly when the language setting is set both from the login screen and from the settings. In addition, I have played around with the language settings in the OPS UI and have confirmed that those get returned properly from the API as well: it is returned under settings.locale and settings.display.locale, both of which were accurate. I do not believe that this is an API from what I can see above, and am not sure it is a bug at all. Will need more insight from the SUI and UI teams to see if there is a disconnect on what the language should be set to. Reassigning to SUI as they're likely the best suited to determine whether it is a bug or not Bumping up the priority, I think this should be a little more important than the general medium severity bz so I want it to be called out. In addition, we have some movement that hopefully we can act upon and not let it go stale. Fixed . Verified in 5.10.0.17.20180927011235_1b5cf54 Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2019:0212 |