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

Adrian Crum closed OFBIZ-2814.
------------------------------

       Resolution: Fixed
    Fix Version/s: SVN trunk

Fixed in revision 1583663.

> 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
>             Fix For: SVN trunk
>
>         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)

Reply via email to