This is a preparator refactor for supporting hosting different Tornado
processes on different servers; to look up which Tornado server we
should be sending the event to, we'll need the realm object.
This should make it possible for there to safely be multiple Tornado
processes running on different ports on the same system.
It may also fix a rare race bug in development, where previously, it
was possible for the Tornados processes for Casper and the main
development server to interfere; I haven't investigated whether this
was a real bug or not, but now those two services will use independent
Tornado files.
We still need to add something to direct traffic between the different
Tornado processes.
This reverts commit 3645bb9225.
This change was incorrect, because the `is_zephyr_mirror_realm`
property on Realm is a property and thus isn't available in the
migration codebase.
Since this migration is only run for very old servers, this should
have no impact.
This will change the hash of the URL when a new tab
gets selected. Vice versa when the billing page is opened
the appropriate tab is selected according to hash of
the URL. This means when the card gets updated the
page would be reloaded correctly to show #payment-method
tab.
On OSX, the user id and group id don't match. So while the previous
code was always wrong, it produced incorrect output there. We can fix
this by replacing `whoami` with `id -g` for finding the current user's
group ID.
When a user clicks the compose `+` button, create a popover at the
bottom right of the screen including buttons for opening a new stream
message or a new private message.
Use CSS to display a `+` button on mobile but keep the more verbose
buttons on desktop. In the future, this button will be used to display
a popop for a new message.
Apparently, the QUERY_STRING property of the report object wasn't
actually a string; since we only care about its string representation,
we should just stringify it.
Apparently, we weren't resetting the query counters inside the
websockets codebase, resulting in broken log results like this:
SOCKET 403 2ms (db: 1ms/2q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 5ms (db: 2ms/3q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 2ms (db: 3ms/4q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 2ms (db: 3ms/5q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 2ms (db: 4ms/6q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 2ms (db: 5ms/7q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 2ms (db: 5ms/8q) /socket/auth [transport=websocket] (unknown via ?)
SOCKET 403 3ms (db: 6ms/9q) /socket/auth [transport=websocket] (unknown via ?)
The correct fix for this is to call reset_queries at the start of each
endpoint within the websockets system. As it turns out, we're already
calling record_request_start_data there, and in fact should be calling
`reset_queries` in all code paths that use that function (the other
code paths, in zerver/middleware.py, do it manually with
connection.connection.queries = []).
So we can clean up the code in a way that reduces risk for similar
future issues and fix this logging bug with this simple refactor.
Guest users can't subscribe themselves to streams, so we shouldn't
display the subscription button at end of stream message view.
Fixes part of #10749.
Guest users can't subscribe themselves to any stream, so we hide the
"Subscribe" button. Previously, it was showing Subscribe button after
a guest user unsubscribed from a stream.
Fixes part of #10749.
The "notification settings" page previously advertised support for
mobile push notifications via checkboxes, even if the server hadn't
yet been registered for push notifications. This was a frequent
source of onboarding pain for new Zulip organizations.
We fix this by providing a clear warning and disabling the relevant
inputs on the settings pages.
Modified significantly by tabbott to correct some tricky logic errors
as well as some copy-paste bugs.
Fixes#10331.
This test started failing recently; the apparent cause is that
sometimes, zerver/lib/generate_test_data.py generates messages
containing bulleted lists, and those don't end with a `</p>` tag since
they end with `</ul>` instead; the result is that this test failed
nondeterministically in CI.
There isn't really a useful version of this check to do that would
cover that case (as well as the entire message body being a bulleted
list), so we just remove the check; I don't think it's ever caught any
actual bugs.
Jack Zhang
Tim Abbott
Yashashvi Dave
Rishi Gupta
Vishnu Ks
Puneeth Chaganti
Marco Burstein
Shikhar Vaish