Age | Commit message (Collapse) | Author |
|
|
|
This has been deprecated for a while and even before that (since 2.5) it
was just an alias, so switching our import should make no difference
other than working on jinja2 3.1.
|
|
AFAICT the system worked just fine with this before, but the
requirements.txt specifically locked in the version thats in Debian
Bullseye.
Generally it's still recommended to use the packaged version (which
worked with both Bullseye and Bookworm already).
Fixes #122 (even though nothing actually changes)
|
|
Jinja2 v3.0 renamed contextfilter to pass_context. Put some code in that
handles both the v3 and v2 name at the same time, as a first step
towards supporting jinja2 v3.
|
|
The qrencode library we've been using is basically dead (and has been
for a while), so add support for the newer pure-python qrcode library.
We keep support for the qrencode one around, so we don't break things
on existing installs, but consider it deprecated and should eventually
be removed.
Fixes #123
|
|
Since some platforms makes it hard to get the same version of jinja2
(and presumably other things) as we need, create a small Dockerfile
with an example based off the Debian version that we know work.
|
|
pgcrypto was only used to set tokens in some migrations,
so in practice it should not actually be UPDATEing any
rows anymore (there should either be no rows, or they're
all updated by now). Once the migration has completed,
all new tokens are set from the python code.
So update the migrations to use the build-in random() function instead,
which is "good enough for this usage", and thereby dropping the
dependency on pgcrypto making new installs easier.
|
|
This is one never seen before and seems to be used for shipping labels.
Bring it in and treat it like any other.
Noted by Christophe Pettus, but not his patch - going for a minimalistic
one. This code may need some further refactoring down the road.
|
|
|
|
|
|
This is deprecated in newer Django, and will be removed in 5.0. We're
using only very little of the library functionality directly, and the
rest of it's already i django, and since Django 4.2 switched the primary
library, we switch as well for it.
|
|
|
|
This allows downloading a json/yaml file with all the claimed benefits
(including information on if they are confirmed or not).
This also adds a tool called fetch_sponsorfiles.py that will parse this
data and be able to download related files, such as "Logo for the
website" benefits.
The details being provided probably need some more going over with some
reasl world experience, so for now this should be considered
experimental.
|
|
|
|
This one unfortunately has to be less dynamic than the one in the
backend, and just hardcode support for Twitter and Mastodon for now.
|
|
|
|
Previously only json as supported for the template integration for
context.json and context.override.d. This adds support for yaml as well
both for a context.yaml file, and for putting yaml files in
context.override.d. If both a json and yaml exists with the same name
(in the root or in the override), then the json will be loaded first and
then the yaml merged on top of it.
YAML has a few features that are really useful for the context file such
as comments and easier on the eyes multi-line string handling, but
fundamentally the handling is exactly the same.
If the `yaml` module is not importable, then yaml files are simply
ignored.
|
|
Generates a list of dependencies on the latest version of each app.
|
|
|
|
|
|
Mention early that source and destination paths should be absolute. Otherwise
the user will only see it at runtime.
|
|
deploystatic.py will erase the unknown files in destpath. It is a wanted
feature which when used carelessly can lead to disaster. While one can not
protect from all disaster cases, a low hanging fruit is figuring out if destpath
is source controlled.
This is admittedly a minor gain, however it also minor to check.
|
|
|
|
This could still do with a lot of cleanup, but at least with this it
works.
Reviewed-By: Andreas Scherbaum
|
|
|
|
|
|
This is complained about more loudly in newer versions of pycodestyle,
and it's a bad idea in general. So rename them all to something more
readable.
|
|
This simplifies deployments since django_markwhat has a tendency to
create conflicting requirements that makes upgrades harder. Showdown
doesn't have that problem, but this way we have a single defined
markdown process instead of having two subtly different ones.
Most of the code behind this adapted from the pgweb project that went
through this some months ago.
Fixes #72
|
|
This requirement was added back in 10b10a8eb but clearly the
rqeuirements list was not properly updated.
|
|
|
|
|
|
This option was the default since virtualenv 1.7 back in 2011, and is
now scheduled for removal. As it doesn't do anything (being the
default), just remove it.
Reported-By: Saurav Shrivastav
Fixes #65
|
|
This can happen on a newly "git gc":ed repository during development.
We'd render the templates fine, but crash on creating
.deploystatic_githash.
|
|
It needs to be decoded from bytes to str.
TODO: see if there is a more holistic fix for this
|
|
A documentation file and a systemd template that should have been
part of da947f59e4b30671da0fd666cdf503b40c1fcf5c but were forgotten.
|
|
* 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
|
|
|
|
|
|
|
|
Instead of loading a single override file in context.override.json, load
every file called *.json in the directory context.override.d.
This is useful for example for the case of downloading the schedule data
into a file and then using it for testing, instead of having to "stitch"
it into place in an existing file.
NOTE! For test cases using context.override.json today, just create a
context.override.d and move the existing override file into this
directory, and things should work like before again.
NOTE! As context.override.json is not supposed to be committed to the
git repository, this should not affect any production installs, but will
affect most local test setups.
|
|
|
|
|
|
|
|
This is required to work with the newer python-markdown package in
debian buster (and others).
|
|
In particular, cairosvg is only used for the PNG format twitter cards,
so most functionality exists without it.
Make sure we import those modules conditionally only when needed and
handle the import exception. Also add an explicit attempt to load them
during system startup and write to the log if it fails, so it doesn't do
so silently.
|
|
Same package, but we want it to be in a different namespace since that's
what we are actually using (and it makes it more certain we're using the
correct one). Also specify version.
|
|
pycrypto is not being maintained, and pycryptodome is theoretically a
drop-in replacement (in practice, it seems it was close)
|
|
While we don't need to restrict variable access (we always expose all of
context.json, and there is no database access through it..), we still
want to block disallowed methods on strings (for security reasons).
|
|
This changes it to it always gets the latest version of django 1.11
(which is the major we're currently on), so we don't have to manually
update it for every minor release, including security releases.
|
|
And python3 is the only thing we support. And the wsgiref dependency
won't install on python3. So get rid of it, of course.
|