| Summary: | Date isn't saved when using Japanese Env. (BRMS) | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
| Product: | [JBoss] JBoss Enterprise BRMS Platform 5 | Reporter: | Rick Wagner <rwagner> | ||||||||
| Component: | Internationalization | Assignee: | Mark Proctor <mproctor> | ||||||||
| Status: | VERIFIED --- | QA Contact: | Sona Mala <smala> | ||||||||
| Severity: | high | Docs Contact: | |||||||||
| Priority: | medium | ||||||||||
| Version: | 5.1.0 GA | CC: | atangrin, lpetrovi, mproctor, rzhang | ||||||||
| Target Milestone: | ER9 | ||||||||||
| Target Release: | BRMS 5.3.0.GA | ||||||||||
| Hardware: | Unspecified | ||||||||||
| OS: | Unspecified | ||||||||||
| URL: | http://jira.jboss.org/jira/browse/BRMS-645 | ||||||||||
| Whiteboard: | |||||||||||
| Fixed In Version: | Doc Type: | Bug Fix | |||||||||
| Doc Text: |
When viewing the BRMS web console in Japanese, if a date was changed the change could be lost. To workaround this issue set the following properties in jboss-brms.war/WEB-INF/classes/preference.properties:
drools.defaultlanguage=ja drools.defaultcountry=JP.
|
Story Points: | --- | ||||||||
| Clone Of: | Environment: |
Viewed from BRMS (not Guvnor) 5.1.0
|
|||||||||
| Last Closed: | Type: | Bug | |||||||||
| Regression: | --- | Mount Type: | --- | ||||||||
| Documentation: | --- | CRM: | |||||||||
| Verified Versions: | Category: | --- | |||||||||
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |||||||||
| Cloudforms Team: | --- | Target Upstream Version: | |||||||||
| Attachments: |
|
||||||||||
|
Description
Rick Wagner
2011-07-20 13:59:01 UTC
Link: Added: This issue Cloned from GUVNOR-1555 Link: Added: This issue depends GUVNOR-1555 Sample repository for viewing the problem. Attachment: Added: repository_export.xml Security: Removed: Public Added: JBoss Internal You can set in Guvnor's preference.properties: drools.dateformat=yyyy/MM/dd drools.defaultlanguage=ja drools.defaultcountry=JA This gets rid of the issue. Can you please explain what is needed to be fixed given that a "workaround" for getting this work exists ? Thanks.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
Bug marked as private - no release note
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1 +1 @@
-Bug marked as private - no release note+Bug marked as private, but this has a help desk ticket so really should have a release note.
I'm not sure of the workflow for removing the private status from this bug, but suggest private be removed to allow for a release note to be generated for this one. In me previous comment it should have read: drools.defaultlanguage=ja drools.defaultcountry=JP I don't think there is any coding fix necessary as this affects any language and country settings. The properties provide means to work with dates for different locales. GSS prioritizes 'medium'. Is it necessary for the customer to perform this step manually? If so I will add the information to the release notes. (Also, this bug is marked private, can that be changed? I can't release note it as long as it is considered private). Thanks Lee Deleted Technical Notes Contents. Old Contents: Bug marked as private, but this has a help desk ticket so really should have a release note.
Technical note added. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
New Contents:
When viewing the BRMS web console in Japanese, if a date is changed the change is lost. To workaround this issue set the following properties in preference.properties: drools.defaultlanguage=ja drools.defaultcountry=JP.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1 +1,2 @@
-When viewing the BRMS web console in Japanese, if a date is changed the change is lost. To workaround this issue set the following properties in preference.properties: drools.defaultlanguage=ja drools.defaultcountry=JP.+When viewing the BRMS web console in Japanese, if a date is changed the change can be lost. To workaround this issue set the following properties in preference.properties:
+drools.defaultlanguage=ja drools.defaultcountry=JP.
Work around exists. Sent to QA.
Technical note updated. If any revisions are required, please edit the "Technical Notes" field
accordingly. All revisions will be proofread by the Engineering Content Services team.
Diffed Contents:
@@ -1,2 +1,2 @@
-When viewing the BRMS web console in Japanese, if a date is changed the change can be lost. To workaround this issue set the following properties in preference.properties:
+When viewing the BRMS web console in Japanese, if a date was changed the change could be lost. To workaround this issue set the following properties in jboss-brms.war/WEB-INF/classes/preference.properties:
drools.defaultlanguage=ja drools.defaultcountry=JP.
Please, check my use case to verify this issue: 1. Set defaultlanguage=ja, defaultcountry=JP in WEB-INF/classes/preferences.properties 2. Run server standalone 3. Go to http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/Guvnor.html?locale=ja_JP 4. Import repository 5. Change date in rule JTest/BIZ.drl 6. Sign out 7. Sign in http://localhost:8080/jboss-brms/org.drools.guvnor.Guvnor/Guvnor.html 8. Check date in rule After this steps I find wrong date in EN location (today's date). When I change either dateformat in properties: dates in JP and EN are same. Problem is that, after finish import of repository all dates are set to today's date. I tried also set deafultlanguage=en and defaultcountry=US between steps 6 and 7, but problem does not disappear. Please can you give me more information about this use case? I have not got permissions to Red Hat Customer Portal Tracker. Hi if you import the repository, all assets' "Created on" attribute will be reset to the time when the repository is imported. This is expected behavior. What you need to verify is the "Last modified" attribute. Did you see this date has been set correctly? I am not sure if we talk about same thing. "Created on:" and "Last modified:" are attributes of asset. But date which I wrote about is content of Rule (condition "birthday less than 31-12-2011"). If I change this condition to "birthday less than 30-12-2011" in Japanese version and open same asset in English version I can see: "birthday less than 15-05-2012". I think that this is not correct. I have exported repository from english version. In the repository, format of date is: 30-12月-2011 English version expects: 30-Dec-2011 That is the problem. If I set date format to yyyy/MM/dd, I must set all dates in repository again but date format is same for Jap and Eng version. - Not sure about existence of date's converter or just put this into administrator's documentation. Hi, setting WEB-INF/classes/preferences.properties with defaultlanguage=ja, defaultcountry=JP should have the problem fixed. The reason why you saw wrong date (current date) when you changed back to English is you've already set env to jp, in this case, English version can not render the date value correctly. If you set preferences.properties to jp, you should always use ?localz=ja_JP to view the repository. Created attachment 584877 [details]
Japaniese version with properties
Created attachment 584878 [details]
English version with properties
I have added attachments. There are screenshots from Japanese version and English version together with actual preferencies.properties. Steps: 1. set preferencies 2. run server BRMS 5.3.0 ER7 Standalone 3. open Japanese version of Guvnor 4. import repository 5. take screenshot "Japanese version ..." 6. shut down server 7. set preferencies 8. run server BRMS 5.3.0 ER7 Standalone 9. open English version of Guvnor 10. take screenshot "English version ..." Hi Sona, thanks for the help. I am now able to reproduce the problem: 1. Set defaultlanguage=ja, defaultcountry=JP in WEB-INF/classes/preferences.properties 2. Use locale=ja_JP to change the date. 3. Export the repository. 4. Set preferences.properties back to the standard English env. 5. import the repository that was exported from jp env 6 .View the date. It is not correct, the date is the current date. This bug makes it impossible to share the rules with colleagues using different local by sending the repository. The only way to store the date in an interchangable way is to store it as long. Such as fix will have high-impact on Guvnor. Rule Templates, dtables, brl are all affected. I suggest we approach this as a doc issue, ie: In order to interpret the date correctly among different intances of guvnor that are using different locals, those guvnor instances need to use same date format, which is drools.dateformat=yyyy/MM/dd Hi Jervis, I can add a note to localization chapter of the admin guide instructing users to change drools.dateformat in preferences.properties. Assign the bug to me if that's how we decide to resolve the issue. Thanks Lee Reassign to Lee. Hi Jervis, I've add a fourth step to the procedure in the localization chapter as follows: 4. Change the Date Format If multiple instances of the JBoss BRMS user interface are deployed with different languages specified, the format of the date must be changed so that each instance can correctly interpret the date. Specify the date format in preferences.properties. Change the date format from: drools.dateformat=dd-MMM-yyyy To: drools.dateformat=yyyy-mm-dd Please, before you publish documentation, check if different date format is save for another issues (like for bz 814865). I will create some test for ER8. We tested guvnor with default format. This issue's fixes have been picked by ER9. Please verify them on ER9. In documentation, the date's format is wrong. There should be yyyy-MM-dd. Small "m" is for minutes not for month. Verified steps from comment #30 for the date format (yyyy-MM-dd). Documentation updated. |