On the backend issue, we'll probably need to add these to the users model and run a migration to update these for existing users. On this frontend issue, we may need some UX to guide us on how we'd like to expose the timezone display preferences.
Ah no worries @jeremy I jumped the gun opening that MR, but this issue covers the scope of what I thought the other MR would cover.
That sounds good, I had played around with just a basic dropdown and checkboxes but happy to wait for some UX, the only other detail might be having the preferences available on the gon object as this is where the frontend will look to read the settings from, from what i could see this gets populated in the backend and injected into the head of the page. But im not sure if this detail is necessary now or later when we actually apply the settings to datetimes throughout the UI.
This issue does not have a milestone but is labeled Deliverable, therefore, considered a missed-deliverable. Please add missed:xx.x label or remove missed-deliverable and schedule accordingly.
Haha, all good @jeremy I had just started playing around with this last week, just adding the form fields to user settings. But im happy to wait for UX direction if we needed something more sophisticated.
But im happy to wait for UX direction if we needed something more sophisticated.
Honestly, that looks awesome to me.
I'll put UX on this since we'll need to schedule this for %11.10 anyway to get some backend support, but I doubt @matejlatin will have many critiques on this
For when we get to this in %11.10, we should consider moving the "Time zone" dropdown to /profile since it's part of the user's profile. I think @matejlatin was thinking about displaying this on the user's profile page as well in https://gitlab.com/gitlab-org/gitlab-ce/issues/51304.
Yes, I believe we've already discussed that this issue should only pertain to setting the user preferences only.
I imagine there are some changes we can make to core helpers and utilties that would update this in most areas of the UI, but I imagine we'll need an epic of sorts to be able to create issues for all the different parts of the UI in order to have other teams roll this change out.
That said, we would probably want to introduce a feature flag, because rolling this out in one shot would be difficult, but we don't want to inconsistently display the time all over the UI either?
we should consider moving the "Time zone" dropdown to /profile since it's part of the user's profile
@jeremy@matejlatin Let me know if we want to go ahead with this, I actually added all three fields to /profile as i didnt realise there was a separate area for preferences (/profile/preferences). Either way I dont think it should have too much impact on the FE where we decide to have the fields. But it might impact the BE task #57620 (closed) a bit.
I'm a bit confused here. Why would we add the dropdown to the /profile page, users are able to change their preferences on /profile/preferences. On /profile we should only show these bits of info.
Hey @matejlatin, I'm not sure if this entirely expected behaviour, but I think preferences and profile information were separated at some point. When i navigate to /profile I see the edit profile form, but going to /<insert-gitlab-user-name>shows my profile information.
I think the timezone belongs in /profile since it'll be fetchable via the User API. This is also something we plan on exposing on the user profile page.
12/24 and absolute/relative are user-specific preferences are NOT fetchable by others and are not really related to your user profile. We have "private profile" and "private contributions" settings available on that page since they're both related to your profile (who can see it, what's on it).
Time preferences extend way beyond the profile, and across the entire application. So to me, they belong in Preferences > Localization.
That does make sense @jeremy I'm happy for that to change, i guess on the frontend not much will change but i think it might need some more BE changes @mksionek