[
https://issues.apache.org/jira/browse/OFBIZ-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740829#action_12740829
]
Bob Morley commented on OFBIZ-2814:
-----------------------------------
Funny you should method that but it actually is on my short list and we were
talking about this today! It actually started from a conversation about a
user's preferred store / preferred facility as part of UI usability to help set
defaults and such and then expanded to include all of the UI presentment
preferences that we can see going into the future. I was going to start a
thread in the forum on this to discuss the best approach and if we could agree
on stuff that should be in the "preferences bag" (I suspect having it be
extensible is a reasonable goal).
At any rate, this fix is simply to fix the bug that was found when I was trying
to change my timezone and jump from app to app.
> 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 is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
