| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
| |
This reverts commit 7342c7f0e19e15ab3c7ba2133a56393c15989f08.
Turns out there are still issues after all.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This will automatically take care of migrating the users from
users.json; you may delete that file.
Note that this removes htpasswd support. We now store (hashed) user
passwords in the database.
See T19 for rationale.
Test Plan: Run this on a testnet for a while, try to break it.
Reviewers: ilbelkyr, #antispammeta
Reviewed By: ilbelkyr, #antispammeta
Tags: #antispammeta, #database
Differential Revision: https://dev.antispammeta.net/D2
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
"id" in the alertlog table refers to the ID name of the alert rule that
triggered, **not** to some sort of unique ID.
This commit rewrites the database schema history used by
DBIx::Class::DeploymentHandler as the previous schemata were utterly
useless (and, in fact, seem to be undeployable).
@Unit193, @Xenthys Clearly you managed to deploy a database somehow. If
you used the legacy `DATABASE.SCHEMA` file and `bin/db_legacy`, you
should be able to update via `bin/db_upgrade`; I've tested to verify
this. (If you //haven't// run `db_legacy` yet, make sure to update to
exactly de9f3deabe35, run `db_legacy`, then update to this commit and
proceed with `db_upgrade`.)
If you used the `db_deploy` script, may Cthulhu have mercy on your soul:
I'm pretty sure that would not actually have worked. That said, it's my
mistake, so if you require further assistance, feel free to poke me on
freenode.
|
| |
|
|
|
| |
For now, mere presence in the table means a given user is authorized to
view stuff. We can make this more granular later on (important for T11).
|
|
|
Fixes T5. Yay! We still need some documentation on this, though.
|
Janik Kleinhoff