| Age | Commit message (Collapse) | Author |
|---|
|
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.
|
|
|
|
* 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.
|
|
|
|
In an effort to close up with PEP8, we should use spaces for indent
rather than tabs... Time to update your editor config!
|
|
While there are probably a lot of edge cases left, there are several
pieces of functionality in this:
* Sponsor sign-up. A new sponsor can sign up, and download their contract
on the site. For low level sponsorship (controlled by a checkbox), they
can generate and pay their own invoice right away, with an "implicit
agreement of the contracf". For higher level sponsorships, they can
download the contract and get instructions to sign it and return by email.
* Sponsorship representative management. This gives each sponsor the ability to add
(and remove) other of their staff to the sponsorship who will then receive
all emails, and be able to make selections per below. This should help those
sponsors that have a more distributed staff, and takes the load off us for
trying to keep track of it.
* Sponsorship benefit management. This gives each sponsor a chance to "claim"
benefits, so we don't have to track it down individually. For example, they
can indicate directly on the website if they want a sponsor table or not.
This will also include uploading images (the size of which will be
verified against the rules), generating attendee vouchers etc. There will
definitely be followups to do manually in the future as well, though
hopefully less than before.
* A message center. All emails to sponsors should be sent through this, and
can as such be linked to which levels they go to. They're kept in the
system, so that when a new sponsor of level X signs up, they can view all
the old emails to that level that has previously been sent, so we don't
need to keep track of back-posting those. This also goes for the case when
a sponsor adds a new representative, per above.
* An admin dashboard (linked from the main events dashboard) from which we
can track the status of sponsorships and their benefits.
The whole feature has to be enabled by enabling the "call for sponsors" box
on a conference, without that all views will be empty for it. This way
we an incrementally enable it, or just chose to enable it for specific
conferences.
There's definitely more style-work to be done, right now things are just
plain rendered in the main website styles with no adaptions. And certainly
many edge cases and processes that can be improved on :)
|
