This commit also includes a few changes in the way we do some queries that
should speed searches up:
* Messages before and after the anchor are fetched in a single query by doing a
UNION ALL on the server. This incurs the cost of an extra sort because UNION
ALL does not guarantee the order that the results are appended, but it saves a
server round-trip.
* Searches involving flags now use a straight froward WHERE clause, which is
much faster than the one that django-bitfield generates (due to limitations of
the Django ORM)
(imported from commit a0db811a9073363cfabcf4b035d02d20dc8fc8a4)
This requires the tsearch_extras Postgres extension. To install the extension,
first install postgresql-9.1-tsearch-extras on both postgres-primary and
postgres-secondary (this would normally be done in a puppet apply, but there are
currently some changes that can't be applied on Postgres machines). Then run
the following as the postgres user on postgres-primary:
$ psql -d zulip -c 'CREATE EXTENSION tsearch_extras SCHEMA zulip;'
In dev environments, you must also run:
$ psql -d zulip_test_template -c 'CREATE EXTENSION tsearch_extras SCHEMA zulip;'
(imported from commit ad0a57c455b3b86002191ac5fb705d8f716f3296)
Note that this change can not currently be applied on postgres hosts due to the
postgres puppet config currently being slightly broken.
(imported from commit 5d8ddeabfd9612d469a048256d22949c0bfa6aba)
This returns us to the original situation where we're not in the
practice of doing database fetches for UserProfile objects in the
Tornado workflow, which should make our performance no longer
alarmingly degrade when memcached gets flushed.
(imported from commit 3580737604c13c9989f120a2242ad4c3eab6e1d1)
This does result in a few more rabbitmq events to be processed (though
a negligible number compared to what we already do), but it saves a
database query from inside Tornado whenever we occasionally have a
cache miss looking up the UserProfile, which is far more important.
(imported from commit a553a00a3004ba27bfb54ffbc3e9c9b170ebae4d)
Whatever text is entered into the search box under users is used
to filter users by their full names. You can use commas to search
for multiple users. Search terms must be at the start of names, so
"st,fr" would match "Steve Howell" and "Leo Franchi" but not
"jesstess." Names are case insensitive.
(imported from commit 822b72883928d3c941d38e9798774d71b0689f30)
This is used by the Android app to authenticate without prompting for a
password.
To do so, we implement a custom authentication backend that validates
the ID token provided by Google and then tries to see if we have a
corresponding UserProfile on file for them.
If the attestation is valid but the user is unregistered, we return that
fact by modifying a dictionary passed in as a parameter. We then return
the appropriate error message via the API.
This commit adds a dependency on the "googleapi" module. On Debian-based
systems with the Zulip APT repository:
sudo apt-get install python-googleapi
For OS X and other platforms:
pip install googleapi
(imported from commit dbda4e657e5228f081c39af95f956bd32dd20139)
Previously we unconditionally showed the "get the desktop app"
banner. Now, if the first user declines to invite people as part of
their onboarding workflow, show the invite banner instead.
(imported from commit f7892fef17c923154a700149b8f5be99e9c03fa0)
We currently only do bulk invites when the first user in the realm
goes through the signup process, so this will help us know if that
step is effective for getting more early users into the app.
(imported from commit c846086185ed28b13d3d4b695a9c8cad913d3bc9)
We changed our endpoint from "get_public_streams" in August, but the
API call whitelist was not updated.
(imported from commit 293c1da8e43c24ad8188ed2096a47992ad3a2c89)
We don't persist how many PMs you have exchanged with other users
across reloads, so immediately after a reload, our
pm_recipient_count heuristic for autocomplete isn't very useful.
This change makes it so that we prefer humans to bots when
pm_recipient_count is not yet a factor (i.e. both users may have the
same value of zero).
(imported from commit 5fd8c969631d3437df83dd6e5ff8f7316dc4ef51)
There were some notable bug fixes between those versions. We are
still far behind the current version (1.3.0).
For the node stuff, I used npm update.
Then for static/third/handlebars/handlebars.runtime.js, I copied
the node version then added back the copyright.
(imported from commit 59bcd2c52540ff88bba2f90cced809cfcb8cd92b)
Make our dev setup more similar to prod by using compiled.js,
instead of AJAX-ing templates on the fly and compiling them
with non-node code. This will make our dev environment more
consistent with prod (to avoid surprising bugs), plus it should
be faster (fewer AJAX calls).
This change also means we don't have to keep two copies
of static/third/handlebars/handlebars.js around.
(imported from commit d8d584b9aa13adcdcce7e424033610d77d2df79b)
Have run-dev.py watch for template changes by calling
`./tools/compile-handlebars-templates forever`. This doesn't
have much effect until the subsequent commit, but it does
alert users to broken templates.
(imported from commit 3fa5f403cabe0057f6f43180f1d09db669d98682)
The "forever" option causes the tool to continue looking for
template changes and, when they happen, to recompile them.
(imported from commit 2fa719a205f02c7c90cc071f99252148a888654f)
Before this change, we were compiling handlebars templates but then
still sometimes used the copy of compiled.js from the previous deploy,
which made zero sense. Since compiling is super fast, we continue to
compile during every deployment, and now we actually use the results
of compiling. Forcing a recompile every time avoids pitfalls like
failing to notice deleted files or failing to notice a Handlebars
upgrade.
(imported from commit 675932428ec420bfe0fd5a5c748a85600206764c)
If a message edit causes a message to become notifiable, we send
a notification to the user, but only if they haven't had any previous
notifications for this message.
(imported from commit cee854de2d42c31a7352a350f79490caf94b613c)
In update_messages() in zulip.js we now set the mentioned flag
on incoming messages, so that they render properly with the
salmon background.
(imported from commit 6df523edbcd567bf8e1fde144f65f35a00548c4f)
After messages are updated, we process the message for alert
word highlighting, just like we do when new messages are
received.
(imported from commit 5538c0f875595df3ec1ac7c4bc45f0fe44c700cc)
When we edit a message, send out UserMessage flags to the recipients.
This sets the stage for making sure that changes related to
user-specific alert words or mentions get sent out to users.
(imported from commit bce1de19acef44b5e106352f261203352ece02b9)
Zev Benjamin
Tim Abbott
Steve Howell
Luke Faraone
Jessica McKellar
Waseem Daher