OFBiz › OFBiz - Dev

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

_‹ Previous Topic Next Topic _›

Classic

List

Threaded

6 messages Options

Nicolas Malin (Jira)

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

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

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.

Nicolas Malin (Jira)

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

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

Bob Morley updated OFBIZ-2814:
------------------------------

Attachment: OFBIZ-2814.patch

> 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.

Nicolas Malin (Jira)

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

In reply to this post by Nicolas Malin (Jira)

[ https://issues.apache.org/jira/browse/OFBIZ-2814?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12740826#action_12740826 ]

Adrian Crum commented on OFBIZ-2814:
------------------------------------

Personally, I would like to see the user's locale and time zone selections kept in the UserPreference entity.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

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

In reply to this post by Nicolas Malin (Jira)

[ 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.

--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.

Nicolas Malin (Jira)

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

In reply to this post by Nicolas Malin (Jira)

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

Scott Gray reassigned OFBIZ-2814:
---------------------------------

Assignee: 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
> 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.

Nicolas Malin (Jira)

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

In reply to this post by Nicolas Malin (Jira)

[ 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.