For negated search terms, we weren't explicitly setting
"negated" to false when callers left it undefined, which was
mostly fine, since undefined is falsey, but it is better to
define it explicitly for debugging/testing purposes.
(imported from commit 68a2790b510d17caed8ca11c38188545d1dcc347)
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)
When we typed "stream:" into the search bar, the empty operand
triggered an error in the Dict class for an undefined key, because
we were using opts[0] as a "defensive" workaround to opts.operand,
but opts.operand of '' is more correct than opts[0] being undefined.
Now we only fall back to opts[0] whe opts.operand is undefined, and
we emit a blueslip error when that happens.
(imported from commit 88a196d3bc3d67689c36bc036f378da744c652f9)
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)
This is yet another change related to phasing out the
[operator, operand] tuple data structure for representing
terms in a narrow.
(imported from commit 508e58fc4eebae8a24a8ae59919ba5d94fc66850)
By using _.all() instead of a for loop, we avoid a tiny bit of
confusing between "break" being for a switch statement and being for
the loop.
(imported from commit cd6e7ff788b50f4dadce93e7f0efcb381bc59270)
If you do a search like id:5 topic:foo and message #5
does not have the topic "foo", we now return zero results.
(imported from commit 8121fac1dbd79024c51af1f310d831dab9242e36)
By having Filter.canonicalize_tuple() call filter_term(),
we make it so that Filter objects get operator/operand
fields in their terms when we initialize this.
This mostly caused test breakage for tests that were doing
assert.deepEqual; now we just check to make sure that the
field we need are there.
(imported from commit 63b2516dc72edeb11e76a1fa4442570b9c605baa)
Consumers of Filter.parse() can now reference
search term parts like so: term.operand, term.operator
(Legacy code can still use term[0] and term[1].)
(imported from commit 06d0da65f13f1eb7e3ba8eac0e69448aab2735ab)
Features:
* Only shows messages in the narrow
* New messages in the narrow will arrive as they are sent
* Works even for streams you're not subscribed to
* Automatically subscribes you to a stream on send
* Doesn't update your pointer
* All searches etc. automatically have the narrow added
(imported from commit 2e12b76849f6ca0f53dda5985dad477a04f7bbac)
We convert sender:me to sender:steve@zulip.com at parsing time,
so users will see the canonicalization in the search bar. Likewise
for pm-with.
(imported from commit aa9951f13d4633cfef85f03e5486d607fdef414f)
When decoding an operand, a + can be converted to a space
only if the operand is not an email address.
(imported from commit 08fc36a579bbe6409137c60c0fa9579fe3ab2c43)
I regressed this recently, thinking that all our operators are
strings, but I forgot about the "near:" operator used in the
"Narrow messages around this time" feature. The user facing
symptom was that the search bar showed up empty instead
of saying near:50, which might actually be the better
behavior, but it certainly was not intentional. :)
(imported from commit fcb93cecbe9a052bb9bc1af7fcac5aecaba5aafb)
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)
Streams are converted to their "official" names now.
Topics are not canonicalized at all.
All other operands continue to be lowercased.
Since we don't lowercase stream/topic at the parsing stage,
we have to modify the predicate function to do the lowercasing
of stream/topic to enable case-insensitive comparisons. This
is slightly more expensive. The server-side predicate
functions are already case-insensitive.
(imported from commit 286f118c6c3ff9d23b37c7f958cab4c0eacd5feb)
This can be squashed with the prior commit or subsequent commit,
or it can just stand on its own, but it's part of transitioning
to a functional change in the next commit.
(imported from commit 155a0cdd28f851810fbedfef1a306e3190bf1c34)
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)
