If a user was logged in and already verified, the resend_verification
link would cause a server error. This fix addresses that by using the
correct syntax to query the username from the request.
In the same fashion limit=BAD fallsback to the default value,
fallback to zero when offset=WORSE.
Also add test coverage verifying limit/offset do the right thing.
Signed-off-by: Loic Dachary <loic@dachary.org>
For some reason the alembic connection wasn't seeing any tables that existed
however the existing connection works well and we shouldn't be creating a brand
new one when we have one ready to use. I've used a little bit of a hack due to our
old version of alembic.
After 0.7.5 of alembic it offers a `Config.attributes` dictionary which is designed to
allow you to pass your connection/engine/whatever to the env.py config script so you're
not required to create new ones. As we're on an older version I just create a dictionary
with the same name and use it as otherwise documented. It seems this is the suggested
fix for #5395 and it fixes#5398 too.
When a user deleted media or other objects any notificationn objects or reports
would cause errors as the object doesn't exist anymore. This now removes them or
sets them to None as expected by the code. This also adds some code to the base
deletion code to make sure this happens when an object is deleted.
Just like we would have in sqlalchemy-migration inspect_table works and
is better than constantly redefining a table in the migration. This switches
the migration to use that method.
The database connection was being set in a alembic.ini config file, if the user
had specified postgres the "sqlite" connection URL in alembic.ini would override
that. We probably should look into this more so i've opened #5395.
When an item is deleted it should be removed from all collections, this commit
makes that happen. It's got two changes:
1. Adds the code so when an object is soft deleted, it's automatically removed from
all collection items
2. Add a migration to fix this issue for those who have tombstones (Graveyard objects)
in their collections because of this bug.
This commit requires you to run a migration
This commit fixes issue 5367 by updating the edit view to be compatible
with recent db migrations.
Signed-off-by: Jessica Tallon <tsyesika@tsyesika.se>
This fixes a few bugs in previous migrations and then also introduces a new
migration for those who had run the previous migrations without encountering
the bugs to ensure that the database is in the same state as those who ran it
after the bug fixes introduced in this commit.
The commit also ensures that all activities are valid, they should be but they
might not be so checks, from now on we should be able to assume that all activities
will always be valid.
Some sqlite migrations were failing due to some problems with sqlite. A
work around has been created for these however it does involve loading lots
of data into memory. If you have a large database you should consider trying
to move to postgres.
