| Age | Commit message (Collapse) | Author |
|---|
|
This allows the upload of a generic file, not just an image. It can be
restricted by mime types if wanted (to for example say only EPS and SVG
files), and will then validate the MIME header. It will *not* attempt
any further validation beyond the MIME header. If no MIME type is
specified on the benefit, then it will accept any uploaded file formats
and leave it entirely to the administrator to handle.
To make this work, also add support to the InlineEncodedStorage to store
metadata, and use that to store the filename so we can reuse it later.
|
|
Previous commit (878d1540) applied the wrong fix. The field should still
be NOT NULL, the bug was actually in the trigger being created in the
earlier migration which was incorrectly missing INSERT. Fix this and
change the field back, which more or less reverts 878d1540 but does it
with a new migration so that any existing data gets fixed.
|
|
Needs to allow NULL on INSERT, which will then get overwritten by the
trigger.
|
|
Store the hash (md5 is good enough here) of the benefit images, and
maintain it using a trigger. This hash is used to implement
etag-handling for downloads of the image. We don't expect that part to
pay off very well since it's logged in users only, but the hash will be
useful in some upcoming patches, and once we have it implementing the
etag handling is basically free.
|
|
|
|
The names of constraints (unique or foreign key) are *not* predictable
between versions. This means that the name of the constraint in the
database will depend on which version of django was used when the
constraint was *applied*, not when it was created - meaning that systems
installed at different times will have different names for the
constraints.
This can cause future migrations to fail because django tries to ALTER
TABLE or DROP CONSTRAINT or such things using the name it thinks the
constraint has, but because of the version used it might have a
different name. Upgrading django does *not* create any form of
compatibility mgiration, so you're basically left with a database that
can't be migrated, unless all migrations are always applied with the
same version. Which is of course not the case when for example a brand
new installation is made.
To work around this limitation, we dump a list of all unique and foreign
key constraints in the database to files, and use those to compare. The
assumption for now is that django will only change the names in major
versions, which means we only need to re-dump these files in major
versions. They should be dumped using a fresh install in an empty
database, and can then be used to backfill old databases with new names.
A command to diff and automatically rename constraints is also included.
Once proven to work it will also be turned into a migration step so it
can be automated properly, but let's verify first. This command is only
capable of renaming incorrectly renamed ones - if there are constraints
completely missing or added that shouldn't be there, it will print the
results but not do anything about it.
|
|
util migration 0002 changes the type of util_storage.data from text to
bytea but confsponsor migration 0018 assumes this column is text when
updating confsponsor_sponsorshipcontract.contractpdf. Adding explicity
dependency between the two ensures they are processed in the correct
order.
|
|
* Remove the hard-coded twitter implementation and replace it with an
infrastructure for pluggable implementations.
* Separate out "social media broadcasting" (public twitter posts) from
"private notifications" (DMs) and invent "private broadcasting"
(notifications sent only to attendees of a conference) and
"organisation notifications" (sent to organisers).
* Add the concept of a Messaging Provider that's configured on a
Conference Series, which maps to a twitter account (or similar in
other providers). Replace "incoming twitter active" flag on a
conference with a setting on this messaging provider for "route
messages to conference". This way the messaging doesn't have to be
reconfigured for each new conference in a series, and we also
automatically avoid the risk of having two conferences getting the
same input.
* For each conference in a series, the individual Messaging Providers
can be enabled or disabled for the different functionality, and
individual channels be configured when applicable.
* Add implementations of Twitter (updated, social broadcasting and
private messaging support), Mastodon (social broadcasting and private
messaging) and Telegram (attendee boadcasts, private notifications,
and organisation broadcasts)
* Add webhook support for Twitter and Telegram, making for much faster
reactions to incoming messages.
* Hardcoded news twitter post accounts, and replaced with
MessagingProviders per above that are not attached to a conference.
* Add a daemon that listens to PostgreSQL notifications and sends out
broadcasts and notifications for quicker action (if not enabled, a
scheduled task will send them out every 10 minutes like before)
* In making broadcast posts, add support for the fact that different
providers have different max length of posts (e.g. Twitter currently has
280 and Mastodon 500), and also roughly account for the effects of
URL shorterners on posts.
* Add a button to registration dashboards to send DMs to attendees that
have configured notification.
* Send "private broadcasts" ahead of any talks to keep people posted of
talks. For now this is always enabled if a channel is set up for
private broadcasts, we may want to consider making it more
configurable in the future.
There are still a lot of tables and files referring Twitter in the tree,
and some of those will be renamed in a future commit to make tracking of
changes easier.
Fixes #29
Fixes #13
|
|
Now that we are not using it as a django field anymore, simplify
InlineEncodedStorage to just natively do the two methods that we
actually need.
While at it, change it to use bytea internally instead of base64 encoded
in text, and add an appropriate unique constraint that was previously
missing.
|
|
This replaces our old custom migrations. NOTE! Since there are some
dependencies in these migrations, they need to be individually faked.
Since we want the django core apps to get upgraded anyway, the commands
that need to be run are:
python manage.py migrate auth --fake-initial
python manage.py migrate admin --fake-initial
python manage.py migrate contenttypes --fake-initial
python manage.py migrate --fake
Note: braintreepayments app not yet migrated
|
