We now simply exclude all cross-realm bots from the set of emails
under consideration, and then if the remaining emails are all in
the same realm, we're good.
This fix changes two behaviors:
* You can no longer send a PM to an ordinary user in another realm
by piggy-backing a cross-realm bot on to the message. (This was
basically a bug, but it would never manifest under current
configurations.)
* You will be able to send PMs to multiple cross-realm bots at once.
(This was an arbitrary restriction. We don't really care about this
scenario much yet, and it fell out of the new implementation.)
We can currently send a PM to a user in another realm, as long
as we copy a cross-realm bot from the same realm. This loophole
doesn't yet affect us in practice--all cross-realm bots are
generally configured for the "admin" realm like the old zulip.com--
but we should lock it down in a subsequent commit.
Having each condition in a separate test was confusing to read,
especially since the tests were doing inconsistent setup, sometimes
calling user2 the user from 2.example.com realm and other times
calling user2 the cross-bot realm, etc.
When the render function is run now, it uses the partial_finder
function to search recursively through files for partials and add them
so that test writers don’t have to.
This means that we no longer have to do any manual work to maintain
the templates.js check that all handlebars templates are rendered by
the node tests.
Previously, var/casper/server.log was overwritten before every run of
run-casper. This commit implements the simplest form of log rotation,
by overwriting server.log only if it has more than 100kb.
Currently, message_edit.edit_message accesses elements of
message_edit_form.handlebars by a number of different means, and in a number
of different places. This commit is the first of two that standardizes it.
Previously we disabled fields in message_edit_form.handlebars that you
couldn't edit. This meant you could see the content of the field, but not
copy it. This commit marks those fields as readonly instead.
Previously,
* We displayed "(no topic)" in .message_edit_topic when there was no
topic;this commit changes that to a placeholder.
* We showed the .message_edit_topic_propagate dropdown when the user
cleared .message_edit_topic, despite the fact that one cannot save
or propagate an empty topic. This commit fixes the behavior.
Fixes#1273.
- Use tornado as proxy server for development environment,
replacing twisted (this doesn't support websockets).
- Upgrade tornado version to 4.4.1 (needs to be coupled to the
above since neither change works without the other)
This change makes most of the logic on set_count() live
on our per-stream topic list widget. We can find the
jQuery object directly now rather than using the
complicated iterate_to_find() method.
Adds a count_X_by_Y_query to counts.py, similar in spirit to a
count_recipient_by_user query, where we would join on the Message,
Recipient, and UserProfile table. Here, we also join on the Stream table in
order to distinguish private and public streams, and we merge the counts for
PM and Huddle type messages into a single subgroup.
We don't want to prepend new subscribers to our list of
subscribers in the settings page when they hit enter; we
want to wait till we get the event from the server.
This is a fairly new regression that was added when we
live-updated peer subscriber changes.