Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

User timezone is not updated when using auth methods != credentials #32165

Open
tomneedham opened this issue Jul 26, 2018 · 6 comments
Open

User timezone is not updated when using auth methods != credentials #32165

tomneedham opened this issue Jul 26, 2018 · 6 comments
Labels
p3-medium Normal priority Type:Bug
Milestone

Comments

@tomneedham
Copy link
Member

Steps to reproduce

  1. Use an apache backend for example, to login to the UI

Expected behaviour

Timezone is update from browser:

$this->config->setUserValue($userObject->getUID(), 'core', 'timezone', $timezone);

Actual behaviour

Since tryLogin is not called, this doesn't get updated.

10.0.9, but likely effects all versions to date.

Tricky thing here is the values are passed into the login form using JS in the login screen - not always possible. Worst case, this has to be turned into its own request, which seems quite expensive.... In theory they needs to be set 'on login' so that the returned page/view/app uses the correct timezone, doing an ajax request would be too late for the first page response. So can we even do this? With apache backends we don\t get the opportunity to pass browser data into the login controller at all...

@owncloud owncloud deleted a comment from ownclouders Jul 26, 2018
@PVince81
Copy link
Contributor

One idea would be to send the timezone in an extra ajax call from the main layout view (ex: when files app appear). But need a flag to not resend for every page reload. The current timezone could be cached in JS localStorage for that.

Would still need a new route for setting the time zone.

Thoughts ? @DeepDiver1975

@PVince81 PVince81 added the p3-medium Normal priority label Jul 26, 2018
@PVince81 PVince81 added this to the backlog milestone Jul 26, 2018
@PVince81
Copy link
Contributor

Yet another option is to make the user timezone be an actual manual user preference in the settings page. Maybe the admin could set a default timezone for all users to save time and the users would have "default timezone" selected there by default, but have the option to also pick a specific time zone.

In this case they'd always see their data with the same timezone regardless where they go. When travelling they'd need to update it.

How do other websites handle timezones ?

@jmdeboer-surfsara
Copy link
Contributor

jmdeboer-surfsara commented Aug 3, 2018

I think @PVince81 has the best idea. Setting a user 'preference' implicitly is not good practice IMHO.

Also, consider the following: Let's say my timezone is Europe/Amsterdam. I fly to the US, but do not log into OwnCloud for a few days. Notification e-mails are in my native timezone. Then I log in, and suddenly, without me knowing or being able to control it, mails are rendered using a different timezone. Same when I travel back home, mails will be in the wrong timezone until I log in. (what if I use the sync client only? would that work too?)

My suggestion: If no timezone is in the user's preference, use the server's timezone as a default. Let the user decide if and when it changes.

@phil-davis
Copy link
Contributor

I also like sites that leave the timezone the same when I travel. I get used to the time in whatever I set as my "home" country and like it to stay that way, rather than jumping around "randomly" as I switch on in different airport transit lounges. So I vote for an explicit manual user preference.

But I'm sure there are those that like their timezone to move automagically as they travel.

@PVince81
Copy link
Contributor

PVince81 commented Aug 6, 2018

@pmaier1 see above proposal

Would be a change of behavior for the better

@pmaier1
Copy link
Contributor

pmaier1 commented Aug 22, 2018

@pmaier1 see above proposal

Yes, makes a lot of sense, agreed 👍

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
p3-medium Normal priority Type:Bug
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants