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 creation timestamp set to zeros somewhere after Dec. 14, 2018 #60

Closed
mrvdb opened this issue Jan 8, 2019 · 5 comments

Comments

@mrvdb
Copy link
Collaborator

commented Jan 8, 2019

After upgrading to latest git (0.7-ish) looking at the user list in the admin settings. The created field of users registered after Dec. 14 or so has the creation timestamp set to '0000-00-00 00:00::00'.

I can't see anything wrong with our particular instance (qua.name) so registering this here to see if others see it too.

db:mysql (mariadb)
multiuser/registration open

@mrvdb

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 8, 2019

A git bisect points me to this revision as the first bad:

6cb8621#diff-320bbef96d874515320f176727a55ea8

@thebaer thebaer added the bug label Jan 8, 2019
@thebaer thebaer added this to the 0.7.1 milestone Jan 8, 2019
@thebaer

This comment has been minimized.

Copy link
Member

commented Jan 8, 2019

Yeah, I was worried about that change. Fixing that now.

@mrvdb

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 8, 2019

Turned out to be a local issue, upgrade of the created column(s) in the mentioned revision was not applied by me apparently.

@mrvdb mrvdb closed this Jan 8, 2019
@mrvdb

This comment has been minimized.

Copy link
Collaborator Author

commented Jan 8, 2019

Perhaps the actual issue here is that db upgrades are easy to miss. In absence of an automated mechanism, should we introduce an UPGRADE file and require a change to it in commits changing the model or other upgrade needing changes?

@thebaer

This comment has been minimized.

Copy link
Member

commented Jan 8, 2019

Yeah, plus I didn't actually include that information with the release notes, which I should've done. I'm working on an automated migration mechanism for the next release, so this problem should go away soon. But if I can't get that in for some reason, yes, an UPGRADE file would be a good idea.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants
You can’t perform that action at this time.