Bug 703908
Summary: | Dashboard portlet names don't change locales | ||||||
---|---|---|---|---|---|---|---|
Product: | [Other] RHQ Project | Reporter: | Mike Foley <mfoley> | ||||
Component: | Core UI | Assignee: | Nobody <nobody> | ||||
Status: | NEW --- | QA Contact: | |||||
Severity: | low | Docs Contact: | |||||
Priority: | low | ||||||
Version: | 4.0.0 | CC: | hrupp, jshaughn | ||||
Target Milestone: | --- | ||||||
Target Release: | --- | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Fixed In Version: | Doc Type: | Bug Fix | |||||
Doc Text: | Story Points: | --- | |||||
Clone Of: | Environment: | ||||||
Last Closed: | Type: | --- | |||||
Regression: | --- | Mount Type: | --- | ||||
Documentation: | --- | CRM: | |||||
Verified Versions: | Category: | --- | |||||
oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||
Cloudforms Team: | --- | Target Upstream Version: | |||||
Embargoed: | |||||||
Attachments: |
|
This may not be behavior we need to change. Currently we store the names of global Dashboards and Portlets. The default dashboard is set to the current locale's string for 'Default'. Custom dashboards are set to the locale's string for 'Custom #' (where # is an incrementing number). The global dashboard names are editable, and so presumably the value in there is the default value or the user has set it to. Either way it can be edited and so the value should not be reset on locale change. Note that deleting all of your global dashboards will result in a new default global dash, again using the default locale for the initial name. The names of portlets are similarly set to the current locale's string for the specific portlet. These names can not currently be edited, although it's conceivable that they could be edited in the future. In that case we would want to leave as is, for the same reason as the dashboard names. But today it's true, these names are stored with the create-time locale and can not be edited. And this results in the reported behavior. It's not clear to me how often this situation would occur but I could imagine maybe users in different locales both logging in as a common user (say, rhqadmin) and maybe being confused by this. It seems unlikely. Also, portlets can be easily deleted and added (as can entire dashboards). Newly added dashboard and portlets would get the current locale's name (note - any custom config would be lost). Lastly, group and resource dashboards/ and portlets are not persisted unless customized. So, in general users would see the current locale. So, I don't see dashboard names as getting any behavioral change. For portlets I think we'd have to be convinced. If we envision them being editable in the future, or if we think the scenario here is unlikely, or if we think delete/add is a reasonable workaround, then leave as is. If we think this is a reasonable scenario then we should stop persisting the (or just ignore the persisted) portlet name, and always display the current locale. We may document the current behavior and that such a user may have two dashboards - one in EN locale and the other in JA |
Created attachment 498327 [details] dashboard portlet still showing japanese locale Description of problem: Dashboard portlet names don't change locales Version-Release number of selected component (if applicable): RHQ 4.0 How reproducible: 100% Workaround: Deleting the Dashboard will bring a new clean one in the current language back, but this is perhaps no option for those multilanguage users. Steps to Reproduce: 1. Use RHQ in Japanese locale 2. Then use RHQ in German locale 3. Actual results: Dashboard portlet names do now switch locales Expected results: Dashboard portlet names do switch locales. Is RHQ persisting the portlets using their display name, rather than their locator/view name? Additional info: