[
https://issues.apache.org/jira/browse/OFBIZ-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12894474#action_12894474
]
Scott Gray commented on OFBIZ-2814:
-----------------------------------
Hi Bob, sorry it has taken so long to look at this issue.
It looks good to me but I have one concern:
I know for our OOTB applications the user is essentially logged in for the
duration of their session, but I'm wondering if the patch addresses a situation
like ecommerce where the app is used with the user perhaps not initially logged
in. If a user is browsing an app without being logged in and decides to change
their timezone then later decide to log in, the timezone they selected will be
replaced with the value in the UserLogin record. I'm wondering if that is
something we really want to happen and I see the potential for it causing
confusion for the user if the timezone transparently switches without them
noticing.
I wonder if perhaps we shouldn't set the timezone, etc. information in the
session unless they actually specify one and instead just always fall back to
the system default. Storing the system default in the session doesn't really
gain us anything and this problem could be resolved simply by not doing it.
What do you (and anyone else) think?
> 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
> Assignee: Scott Gray
> 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.
