Bug #15285
openTimezone is saved as an empty string instead of nil after changing to a timezone and back to "Browser timezone"
Description
It appears as if when saving a user as "Browser Timezone" after changing the timezone to something other than "Browser Timezone" that the value is saved as an empty string instead of nil.
Check it out:
katello=# select count(id) from users where timezone = '';
count
-------
1
(1 row)
(byebug) cookies[:timezone]
"America/New_York"
(byebug) User.current.try(:timezone)
""
Which will obviously cause this time zone code [1]:
client_timezone = User.current.try(:timezone) || cookies[:timezone]
Time.zone = client_timezone if client_timezone.present?
to not set the correct timezone since User.current.try(:timezone) will be true and thus client_timezone.present? will be false.
Steps to Reproduce¶
- Change a user's timezone to something other than "Browser timezone"
- Change the same user's timezone back to "Browser timezone"
- Note that user.timezone is an empty string
Updated by Walden Raines almost 8 years ago
- Subject changed from Timezone is saved as an empty string instead of nil to Timezone is saved as an empty string instead of nil after changing to a timezone and back to "Browser timezone"
Updated by The Foreman Bot over 7 years ago
- Status changed from New to Ready For Testing
- Assignee set to Shlomi Zadok
- Pull request https://github.com/theforeman/foreman/pull/3886 added
Updated by Shlomi Zadok over 7 years ago
- Status changed from Ready For Testing to Rejected
- Target version deleted (
1.5.3)
Please see discussion at https://github.com/theforeman/foreman/pull/3886
Feel free to re-open the pull request and the issue should you think we're are wrong.
Updated by Dominic Cleal over 7 years ago
- Status changed from Rejected to New
- Assignee deleted (
Shlomi Zadok)
I think this issue is still valid, the code that is given in the description (from application_shared) is still present and has the fault described. If the DB timezone is set to an empty string instead of nil, fallback to the cookie timezone doesn't occur.
It appears that the approach in the PR of storing the cookie in the DB on each request was rejected, not that the bug described here is rejected.
There's no need to store the cookie in the DB to fix this, only to ignore empty strings in the DB too.