[jira] [Reopened] (OFBIZ-2814) Changing the timezone in application only applies to the current session

["Adrian Crum (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/OFBIZ-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Adrian Crum reopened OFBIZ-2814:
--------------------------------

      Assignee:     (was: Scott Gray)

> Changing the timezone in application only applies to the current session
> ------------------------------------------------------------------------
>
>                 Key: OFBIZ-2814
>                 URL: https://issues.apache.org/jira/browse/OFBIZ-2814
>             Project: OFBiz
>          Issue Type: Bug
>          Components: ALL COMPONENTS
>    Affects Versions: SVN trunk
>            Reporter: Bob Morley
>         Attachments: OFBIZ-2814.patch
>
>
> I believe this applies to all application except e-commerce and webpos.
> If you logon to an application and change your locale and timezone using the preferences at the top the system will set those new values in the session.  When you logout and your session is flushed and the logon screen is rendered a new session is established and the defaults (for the website/product store) are use for this rendering.  The locale (interesting enough) is not stored in the session but the timezone is.  When a user authenticates to the system their last selections are _not_ applied in the session.  Because the locale is not cached, it will show properly (user's lastLocale) however because the TimeZone is cached the system will not use the user's lastTimeZone.
> Proposed fix
> -- update LoginWorker.doBasicLogin to set the lastCurrencyUom, lastLocale, and lastTimeZone from the newly authenticated userLogin (if these values have been specifically set by the user)
> -- update UtilHttp.getLocale(HttpServletRequest) to not only get the locale for the request, but also to put it in the session (was not doing this before but this is consistent with similar getTimeZone)
> -- update UtilHttp.getTimeZone(HttpServletRequest) to verify that the incoming parameter is not null (similar to getLocale)
> The part I would like verification on is the decision to start using the session to store the locale -- while this is exactly how the TimeZone is handled (and used in piles of spots -- gathering context, whenever an event needs locale, etc).
> Patch will be attached in a few minutes.



--
This message was sent by Atlassian JIRA
(v6.2#6252)