| Age | Commit message (Collapse) | Author |
|---|
|
Since Linkedin doesn't support wildcards, having the providerid in the
URL required whitelisting individual URLs which was very annoying.
Instead overload it into the state field and use a shared URL.
In passing, fix the redirect after attaching linkedin to a shared news
provider. The attachment worked fine but the redirect went to the wrong
page.
|
|
|
|
|
|
This caused an error in the view when setting up a new oauth client
(such as a linkedin page). It happened *after* the actual configuration
was completed, so one just had to reload for things to work, but it
still shouldn't error like that.
|
|
|
|
For now, this provider only supports basic publishing of entries as
post. It does not support any polling, and it does not support
collecting sponsor/speaker id's and highlighting them in notices. This
can be added later, but it can't be done properly without linkedin app
credentials that are not rate limited (the default), and you can't get
those credentials without already having an app.
As linkedin doesn't support the offline code flow for logins, this also
implements an oauth endpoint for incoming oauth flows for messaging
provider.
Finally, unlike the other messaging providers, linkedin actually expire
their oauth tokens - 2 months for the access token and 12 months for the
refresh token. To handle that, implement token refresh as part of the
validation flow, and simply flag that one as failed if the login doesn't
work.
|
|
This is required (in some cases? Because many seem to work) to publish
deep links on modern android versions. Basically we tie in the
publishing certificate we use in the play store to our domain, thereby
allowing it to "capture" those links directly.
Per complaints from the play console, and their suggested fix.
|
|
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
|
|
* 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
|
