The information here was recently added to manage-who-can-join-and-invite.
Arguably this is one we should save, since it is a distinctive feature not
offered by all of our competitors, and it gets some additional visibility by
being in the left sidebar. The model of having multiple things in the
sidebar pointing to the same article is getting messy though, and as our
feature count increases the cost of having stuff in the left sidebar is
increasing as well.
The current code for detecting which image to add the `selected` class
to is `preview_source.match(src)`. With the new thumbnails, this no
longer works because thumbnail URLs include a `?`, which has its own
RegEx significance. To solve this, check for equality instead of using
RegExes.
Various pieces of our thumbor-based thumbnailing system were already
merged; this adds the remaining pieces required for it to work:
* a THUMBOR_URL Django setting that controls whether thumbor is
enabled on the Zulip server (and if so, where thumbor is hosted).
* Replaces the overly complicated prototype cryptography logic
* Adds a /thumbnail endpoint (supported both on web and mobile) for
accessing thumbnails in messages, designed to support hosting both
external URLs as well as uploaded files (and applying Zulip's
security model for access to thumbnails of uploaded files).
* Modifies bugdown to, when THUMBOR_URL is set, render images with the
`src` attribute pointing /thumbnail (to provide a small thumbnail
for the image), along with adding a "data-original" attribute that
can be used to access the "original/full" size version of the image.
There are a few things that don't work quite yet:
* The S3 backend support is incomplete and doesn't work yet.
* The error pages for unauthorized access are ugly.
* We might want to rename data-original and /thumbnail?size=original
to use some other name, like "full", that better reflects the fact
that we're potentially not serving the original image URL.
Previously, thumbor.conf read LOCAL_UPLOADS_DIR from
zproject/settings.py by calling get-django-setting, which ends up
importing Django (taking 250ms, and requiring a full Zulip virtualenv
to be installed on the system).
The new system (in production) just imports prod_settings.py, which
has a lot fewer dependencies and is also a lot faster.
We add this dependancy to thumbor for no use other than making an
import possible in one of the upcoming commits. Basically we wanted to
import LOCAL_UPLOADS_DIR from zproject.prod_settings or
zproject.dev_settings and prod_settings_template.py imports
django-auth-ldap (which depends on python-ldap and django).
This seems counterproductive, but it makes it possible for us to save
significant thumbor server startup time that would have been consumed
in `get-django-setting`, and once thumbor supports Python 3, we'll
probably be merging the virtualenvs anyway (in which case this change
would become a no-op).
We need to use the value of SECURITY_KEY read from
/etc/zulip/zulip-secrets.conf (using get_secret), and also we disable
a few Thumbor features that we're not using. We also fix access to
secret keys by getting their values using get_secret.
Previous commits have fully implemented the logic for stream email
notifications; this final commit adds support for configuring it to
the UI.
Fixes#6511.
This adds support to the event queue system for triggering
missed-message notifications (whether push or email) to support the
stream push notifications feature.
This modifies the logic for formatting outgoing missed-message emails
to support the upcoming stream email notifications feature (providing
a new format for the subject, etc.).
Because we're passing through the trigger for notifications to
do_send_missedmessage_events_reply_in_zulip, we don't need to go back
to the database to determine which messages actually mentioned the
user.
This change converts our logic for determining whether the current
user was mentioned in a group of messages from the implicit "if it was
sent to a stream, it's a mention" to the explicit "we actually know
there was a mention in the message". This is an important
prerequisite for our upcoming feature to support getting email
notifications for streams always (even without a mention).
Previously, maybe_enqueue_notifications had this very subtle logic,
where it set the notice variable only inside the block for push
notifications, but then also used it inside the block for email
notifications.
This "worked", because previously the conditions for push
notifications were always true if the conditions for email
notifications were, but the code was unnecessarily confusing. The
only good reason to write it this way is if build_offline_notification
was expensive; in fact, the most expensive thing it does is calling
time.time(), so that reason does not apply here.
This was further confusing, in that in the original logic, we relied
on the fact that push notification code path edited the "notice"
dictionary for further processing.
Instead, we just call it separately and setup the data separately in
each code path.
This data will be required for correctly implementing the upcoming
stream_push_notify feature; it also helps support cleaning up the code
for the existing stream mentions logic.
Because in upcoming commits, we'll want to pass additional per-message
data into do_send_missedmessage_events_reply_in_zulip, we need to
expand the format for how we represent messages to account for that.
This refactors the generate_topic_history_from_db_rows function to not
depend upon the assumption of rows passed as parameter to be sorted in
reverse order of max_message_id field.
Additionally, we add sorting and some tests that verify correct
handling of these cases.
In this commit we add a new endpoint so as to have a way of fetching
topic history for a given stream id without having to be logged in.
This can only happen if the said stream is web public otherwise we
just return an empty topics list. This endpoint is quite analogous
to get_topics_backend which is used by our main web app.
In this commit we also do a bit of duplication regarding the query
responsible for fetching all the topics from DB. Basically this
query is exactly the same as what we have in the
get_topic_history_for_stream function in actions.py. Basically
duplicating now is the right thing to do because this query is
really gonna change when we add another criteria for filtering
messages which is:
Only topics for messages which were sent during the period the
corresponding stream was web public should be returned.
Now when we will do this, the query will change and thus it won't
really be a code duplication!
We already include the issue title in the topic. But if one chooses
to group all gitlab notifications under one topic, the message body
is misleading in the sense that only the Issue ID and the description
are displayed, not the title, which isn't super helpful if the topic
doesn't tell you the title either.
I think we should err on the side of always including the title in
the main message body, which is what this commit does.
Fixes#9913.
Anders Kaseorg
Lyla Fischer
Rishi Gupta
Steve Howell
Tim Abbott
Marco Burstein
Joshua Pan
Aditya Bansal
Sarah
Eeshan Garg
Harshit Bansal