Before this change, we were incorrectly trying to do local
filtering on negated has searches.
(imported from commit d1a6f1feef6b3cc1c984eb91a73cd16c4e66874e)
We still don't show this in the frontend, aside from our usual "Not
delivered" message that we also show when you send to a non-existent
user.
Addresses #2349
(imported from commit 2f348b15a4d539987ddbcccbbf40e2be87c1f92d)
We show a user as "on mobile" if:
* They are only active on mobile
* They are inactive on all devices and can receive push notifications
(imported from commit 0510b9371727cd19c72f6990df7112921c36ad48)
This doesn't affect code when not in testing. It shaves 7 seconds off of casper
test time on my machine.
(imported from commit 7e27fa781bcf16f36d9c8f058427ba57c41068bd)
Normally, casper delays checking the waitFor condition for 100 milliseconds and
further does not act on that check for another 100 milliseconds. This is just
silly.
(imported from commit ad046ceda81abda5c609ce25ef0d4fb27d3da716)
send_message -> then_send_message
send_many -> then_send_many
wait_and_send -> then_wait_and_send
Hopefully this makes it clearer that they should not be called inside of steps.
(imported from commit 4fcc971817b25056100311ba55303da2c5527f0f)
Casper was calling casper.then(then) instead of calling the callback directly.
This meant that the callback was being added as a step, which worked, but was
not consistent with the rest of the casper model.
(imported from commit b3bf916f7c56dd3d4e7be3569ebdf9d3045cd085)
This will make it slightly easier to consume the data from our clients.
Ref:
RFC 6585 §4
(imported from commit 6d323dc25db78a6d84a163add950f039e03e73d3)
In a test run with a hand-constructed query, this sped up the query time from
280ms to 50ms.
(imported from commit 8cbe199ca50a487491d13d6d6ef940ea668c1038)
We can't just check that the realms are the same because ist.mit.edu is an open
realm and uses @mit.edu email addresses.
(imported from commit 7dbaa81cea6e4f82563dfc0cfe67a61fe9378911)
See #2357. We now support `~~~ .py ` with that trailing space.
Note that the test coverage is Python-side only due to
bugdown_matches_marked being set to false, since we don't yet
support language syntax on the client side.
(imported from commit ccd5fcb0eee01478d349161400103480678d7486)
Previously, if you searched for "in:home search:foo", we
weren't making "in:home" a public operator, so the back end
wouldn't know to exclude muted messages, but the front end
also wouldn't exclude muted messages, because it assumed
that queries with "search:" in them were fully narrowed by
the back end.
Prior commits made it so that the back end is now capable
of doing "in:home" narrowing, so to get the properly narrowed
results, we simply needed to make in:home be a public operator
in this commit. We also made in:all be public for convenience,
although it's essentially a no-op.
(imported from commit e4a8b10813b50163c431b1721bd316b676be1b83)
Steve Howell
Leo Franchi
Luke Faraone
Zev Benjamin
Waseem Daher
acrefoot
Jason Michalski