This slightly reduces code duplication and in the future the {api,json}_ methods
will hopefully go away, leaving only the _backend methods.
(imported from commit 82a6e4a2ff2ba5d272068e9ff043ea47a1a8d278)
Instead we now rely on the request._client value, which we were previously
passing along to s_m_b in all but one case.
For that one case, we just modify the Request object to include the value
beforehand.
(imported from commit 542f38f94bc447149cd4d2efaa5e8f48f756725b)
This can result in a significant performance benefit because we only
need to update the columns that changed..
(imported from commit 42bef1fcc58ad79bd864f89263fe82e90743ee5b)
This is a lot cleaner, and also cuts about 50-70 ms off of page load time in
local testing (with lots of users), presumably because there's less work to be
done by the slow Django template engine.
(imported from commit 257b700238ee5d9a4ae00a53011ed5bce018124c)
This will automatically fix bugs such as one in which
internal_send_message didn't properly strip() the subject argument
before sending a message.
We change the recipient_type argument to internal_send_message to take
the recipient type name (e.g. 'stream') both to better fit the API and
also because the previous code incorrectly handled huddles.
(imported from commit 78c2596d328f6bb1ce2eaa3eed9a9e48146e3b6a)
This is preparatory for using this new arguments checking function in
internal_send_message as well.
(imported from commit 578e09c50b8a700c019c7dd235b2d9527af34e39)
This fixes a nondeterministic test failure for me.
The first message sent in the test suite appears to get dropped. I don't know
why this is, and I'm pretty sure it was an existing bug. This message used to
be the one disabling the tutorial, which might explain why that didn't always
work.
Regardless, this commit at least makes the test suite usable, and we can work
on fixing that bug later.
(imported from commit 063e40871b9883e3a6dab93a4e0a51c5b2dae4b7)
This should substantially decrease the amount of server load generated
by the userpresence system.
I tested that this indeed was indeed saving one query on
/json/update_active_status requests on my laptop with 2 users from the
humbughq.com realm logged in.
(imported from commit 03e9d4eb95b9f664d489862684ae162db2076e08)
It's closer to a presence query than an update, and more importantly
this moves this out of Tornado -- previously Tornado was spending at
least 3ms per recipient on messages sent to the MIT realm fetching all
this data to return back to users. This should save around 100ms per
message sent to a popular stream the MIT realm -- but more
importantly, each such event is 100ms during which Tornado is not
processing other messages.
(imported from commit 134169f0fdcd9f6640fda957edc4a28b07783d8e)
We were previously having an issue where the tutorial could
be pre-empted if you got a few messages while you were first
logging in.
I have some reservations about this being slightly fragile, and a
better approach might be to just have a bit that we use to determine
whether or not you've already seen a tutorial. (Or potentially that
checks whether or not you've ever sent a message.)
(imported from commit f8858f64a36bcd25887b76314caff283929f340c)
When narrowing, we use the selected id in the home view as the anchor,
and if the user is new and hasn't selected any messages yet (or moved
the pointer since first using humbug), their home view selected message
will be -1. Rather than failing to get_old_messages for any narrows starting
from that point, return all matching messages.
(imported from commit 72cfe392d9ac01ed41abc8eadf0f47240e374665)
I find that I never use it, and I don't totally like our
experience in the app to be different from our users'.
Admittedly, this is a small way in which that's the case :)
Finally, since we do usability studies in @humbughq.com,
the link appears there too, and I'd like it not to.
(imported from commit 1225c4ae79de52fa98b21ce00a6542df76b667ea)
Prior to this change, any stream message sent by internal_send_message
could only be in the realm of the sender.
This was a problem most notably for... the tutorial bot, with the
hilarious consequence that the tutorial worked fine in humbughq.com,
but failed to start anywhere else.
(imported from commit 33a904a28e3a57e1a2cf9172c2e2a75b50967a50)
Require POST method for /accounts/logout. This has the side effect of
automatically enabling Django's CSRF protection.
(imported from commit 44b1b6ebaadc1c03006e21ae54ac768e31234801)
But only allow them to send to tutorial-<<your username>>.
The idea being that this helps reduce potential abuse from this JSON
call. (Because otherwise, anyone could call into this endpoint and
have the tutorial bot send random messages to random peoples's
streams.)
(imported from commit 471d4348d7ad43858b5df240e4f1dceba006aab6)
After c1d98239 the function works in CasperJS as well.
Reverts some of 90f4d6ac3ddb387e74051b9af2c230698fa94479.
(imported from commit 3579df33930bb34dc081908b84900905eee6d270)
The idea here is: part of the onboarding tutorial is going to
be you talking to the tutorial bot and it talking to you, from
our Javascript.
The reason it's driven by Javascript is that then in principle we can
do nice stuff like making popovers appear in places to point things
out to you, whereas if we were to do it strictly server-side, doing so
would be a lot harder.
The downside to doing it in Javascript is that you don't get any of
the Markdown rendering, since that happens on the server. So instead
we add this call where you give it a message, and it responds by
having the tutorial bot send you that message.
I don't think there are any security concerns here because
(1) The bot only messages you -- so you can't use it to make someone
else think that the system is telling them to do something
(2) If there were an issue associated with having the server parse
arbitrary Markdown, you could just trigger the issue by sending
a message yourself.
(imported from commit b34f594dab6be6bcb81899278ae1cbe447404468)
Luke Faraone
Tim Abbott
Zev Benjamin
Keegan McAllister
Jessica McKellar
Leo Franchi
Waseem Daher
Reid Barton
Jeff Arnold