This was causing glitching where if you narrow so that zfilt has only
one message, and add messages on top (e.g. via get_old_messages), and
then add messages on bottom (e.g. by receiving one), we end up with
the bookend row missing. One can make this happen with narrowing,
but, this situation happens every time with time travelling.
(imported from commit 71d85980d8aa9431a17b33e9e5111fd3f76cecf3)
authenticated_api_view and authenticated_json_view call
update_user_activity with a client generated using
@has_request_variables with a default of e.g. get_client("website").
Because that get_client call only happens once on importing the
module, if those client objects didn't exist previously in the
fixtures, then the first test will generate objects with ids 2 and 3,
and then the second test will dump the database, restore from the
fixtures, and then eventually generate client objects with ids 4 and
5. But since the default values were only computed at module load,
we'll still end calling add_user_activity with client objects with ids
2 and 3, which don't exist in the newly restored database.
Fix this madness by just making sure those two client objects exist in
the database.
(imported from commit d940e129d077a560d9a0f96ec3daa2e16ce21c8b)
If the message doesn't exist, rows.get returns an empty jQuery object, not
'undefined'.
(imported from commit 40620f3e4853a662cb93939bf7f0695f81298777)
Previously, if the client was not interested in pointer updates, they
would still return early from get_updates() when the pointer was
updated.
(imported from commit ef9d8b5678b7e72f799840148577651ee10d47ad)
Realistically, if there is a pointer update, no other client is going
to have the same pointer. If they do, the client can ignore the
update.
(imported from commit ca2db60ed7a7c5e4b50a9fa8d350985460922a50)
This is so we only send a single pointer update when the user scrolls
through a bunch of messages at once.
(imported from commit 20d239d7179e5f57ada99968361a0f9b7b18c591)
The assertion-checking callbacks were never called before. Now they will at
least get called when the view invokes handler.finish() before returning, i.e.
the return_messages_immediately case.
I fixed up the assertion-checking callback for one of the test cases. For the
other two it wasn't clear what to do -- one has been known-broken for a long
time -- so I just removed them.
"Fixes" #277 in as much as that test case is gone now.
(imported from commit 82d1db26f36f82f24aa5b7ff9e5aa65ce24c9a8f)
Run this script on an existing realm to create or change default
streams, which new users will get upon account creation.
(imported from commit 8938dcbd3520d97d25b4c6ca783d35c9aef52df0)
Ensure that every result has one of:
* find what you typed in
* search for what you typed in
* Narrow to a stream related to what you typed
* Narrow to a person related to what you type
(imported from commit 2178f17932f951a48f53d982ef660942562b55dc)
Tim Abbott
Keegan McAllister
Zev Benjamin
Luke Faraone
Jessica McKellar
Jeff Arnold
Waseem Daher