Typing "stream:foo -topic:b" leads to "stream:foo -topic:bar" properly
as a suggestion now.
(imported from commit bb0acf52744f7b13977a3db5d3c130d1402b09b7)
Behind a feature flag you can now do searches like this:
-pm-with:othello@example.com is:private
The "-" in front of "pm-with" tells us to exclude messages
with Othello from our search. We support "-" in front of
all operators, although the behavior for "-search:" and
and "-near:" doesn't really change in this commit.
Note that the filtering out of "negated" predicates only
happens on the client side in this commit. On the server
side we ignore negated predicates and send back a superset
of the results.
(imported from commit 6cdeaf32f2d493fbbb838630f0da3da880b1ca18)
The filter_term() function was supporting the transition
from using tuples for search terms to using dictionaries,
but now all of the JS code should be dictionary-compatible.
(We had already abandoned the tuples safety net on staging,
and a couple days of use have given me confidence we can
pull the shim code.)
The one side effect this change has is that search terms will be
initialized to {} instead of []. This distinction matters
when it comes to calling JSON.stringify on the search terms.
(imported from commit 1fbe11011d8953dbea28c0657cbf88384d343e00)
We have shim code that makes our internal narrow operators
support both a tuple interface and an object interface. We
are removing the shim on staging to help expose any dark
corners of the code that still rely on operators being
represented as tuples.
(imported from commit f9d101dbb7f49a4abec14806734b9c86bd93c4e1)
In the early days of the node tests we didn't have an index.js
driver, so each test set it up its own environment. That ship
has long since sailed, so now we just require assert in index.js
as a global and make it so that the linter doesn't complain.
(imported from commit 1ded3d330ff40603cf4dd7c5578f6a47088d7cc8)
Having to explicitly call out the underscore/Dict dependencies
in nearly every test has proven to be more cumbersome than helpful.
We never monkeypatch those modules in the tests.
(imported from commit 49ef70c835edd4e22a5869eda9235ef3ffc3c59b)
There was a bug where you would type "is:private je" into the search
suggestion and see undefined:jesstess@zulip.com. Now we use
the "pm-with" operator. The search suggestions for people are kind
of complicated now, because there is some overlap between
get_private_suggestions and get_person_suggestions.
(imported from commit 7d330f34f4a433995420de6eb90cb41229b70272)
I'm trying to move well-isolated methods out of narrow.js, so that
narrow.js is more strongly focused on UI/ajax interactions and
big, heavy lifting stuff. The logical home for parse/unparse
seemed to be Filter, and they brought along two private methods
with them. The big code moves involved trivial follow ups
like s/exports/Filter/.
(imported from commit ace0fe5aa1c7abce0334d079ba9eb8d9a57bd10f)
The functions add_dependencies() and set_global() are convenience
methods that allow you to modify the global namespace while
the current file is running but then have it be cleaned up
by index.js when you're done.
(imported from commit f75b8a10c19f773a8d2d3a8fa4bc39b1679566fe)
1) The class Filter now lives in its own module.
2) The function canonicalized_operators() is now a class method on Filter.
3) The function message_in_home moved to filter.js and became private.
4) Various calling code had to change, of course.
5) Splitting out Filter helped simplify a few tests.
(imported from commit e41d792b46d3d6a30d3bd03db0419f129d0a2a7b)
There are also one or two places we don't need to use it for security
purposes, but we do so for consistencey.
(imported from commit aa111f5a22a0e8597ec3cf8504adae66d5fb6768)
If you entered "stream:Denmark " in the search box, we would show
you two suggestions for "stream Denmark", despite our duplicate
detection, because we didn't canonicalize the suggestion that is
literally based off the user typed query, and so the other way
of generating the "stream Denmark" suggestion created a duplicate.
Now all the suggestions we generate are canonicalized, so the
generalized duplicate detection can work.
(imported from commit 52bf08ccf9bb2e2260ca8c20690169aead3732ab)
This needs to be deployed to both staging and prod at the same
off-peak time (and the schema migration run).
At the time it is deployed, we need to make a few changes directly in
the database:
(1) UPDATE django_content_type set app_label='zerver' where app_label='zephyr';
(2) UPDATE south_migrationhistory set app_name='zerver' where app_name='zephyr';
(imported from commit eb3fd719571740189514ef0b884738cb30df1320)
