We now will match an alert word even if it is used at the boundry of
bolding, backtick escaping, or caret quoting.
Closes trac #2186.
(imported from commit 984bc63eb621772c95a01ca5c5bfeb190767f71f)
For the Filter helper functions above, we generally want to
ignore negated search terms, since their existence should
really only impact filter predicates and nothing else on the
JS side. The exception is search, where even the existence
of a negated search needs to be noted to know that we can't
apply a filter locally.
(imported from commit 8bbb410a85fefed549d359e4c779a134ad830c11)
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)
This commit doesn't change any functionality, and it is
designed to make diffs for upcoming changes related to
negated conditions a bit easier to read. This diff
looks a bit noiser than it really is due to some
reindentation of continuation lines.
(imported from commit 64c1cba98faa4bad4eaad122dd3de119caa880c0)
This this removed one forced relayout of the page on unnarrow. This
saves about 100ms for me.
(imported from commit 0755f425abbe3d99b8a99765549a5bbf3c620b9a)
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)
The narrow_parameter convert now converts tuples of
(operator, operand) into dictionaries so that downstream
functions/classes deal in dictionaries. This
affects get_old_messages_backend, messages_in_narrow_backend,
and NarrowBuilder.
(imported from commit 7e8cb887f7872ec687acd8c4857d1d5222ab0d5f)
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)
Before we deploy this commit, we must migrate the data from the staging redis
server to the new, dedicated redis server. The steps for doing so are the
following:
* Remove the zulip::redis puppet class from staging's zulip.conf
* ssh once from staging to redis-staging.zulip.net so that the host key is known
* Create a tunnel from redis0.zulip.net to staging.zulip.net
* zulip@redis0:~$ ssh -N -L 127.0.0.1:6380:127.0.0.1:6379 -o ServerAliveInterval=30 -o ServerAliveCountMax=3 staging.zulip.net
* Set the redis instance on redis0.zulip.net to replicate the one on staging.zulip.net
* redis 127.0.0.1:6379> slaveof 127.0.0.1 6380
* Stop the app on staging
* Stop redis-server on staging
* Promote the redis server on redis0.zulip.net to a master
* redis 127.0.0.1:6379> slaveof no one
* Do a puppet apply at this commit on staging (this will bring up the tunnel to redis0)
* Deploy this commit to staging (start the app on staging)
* Kill the tunnel from redis0.zulip.net to staging.zulip.net
* Uninstall redis-server on staging
The steps for migrating prod will be the same modulo s/staging/prod0/.
(imported from commit 546d258883ac299d65e896710edd0974b6bd60f8)
Apparently the "inline" treeprocessor is what runs the inline
patterns. Also re-enable the rewriting-to-https support.
(imported from commit 2fde2c1f15217a784f26b16db25ee745f424f2f0)
Have the server send down the stream's id for removal
events, and have the client use that id to look up the
stream in its internal data structures. This sets the
stage for eventually just sending the stream id (and not
the stream name) down to clients, once all our clients
are ready to use the stream id.
(imported from commit 922516c98fb79ffad8ae7da0396646663ca54fd0)
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)
Here, we don't want to check the uploading users' realm when determining
message privacy, because that'll prevent non-Zulip users from having
email-mirror-uploaded images. Instead, we just pass along the target
realm for the message explicitly to upload_message_image()
(imported from commit 6891261552135b1f41ff9da55ffe963ee5000556)
Our overall guideline is the type names for events are singular, and the list of
events of that type are plural. 'subscriptions' was not following this guideline
and (potentially as a result) had a bug where it was impossible for clients to explicitly
subscribe to subscription change events properly.
(imported from commit 7b3162141fd673746e0489199966c29ea32ee876)
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)
The JS code can now call stream_data.get_sub_by_id() to get
a sub from a stream_id. Subs have stream_id due to a prior commit,
and we keep track of the mapping in stream_data's subs_by_stream_id
variable.
(imported from commit 409e13d6d2e79d909441a66c85ee651529d15cd2)
The tutorial introduces "engineering" messages that might not
be in the user's normal subscription, and they would get a gray
border if we did not override the stream color. Before this change,
we accomplished this by overriding the core data structure in
stream_data.js. Now we are a bit more future-proof; we only
override stream_color.default_color.
(imported from commit 0d0845b72f766912679f5aa7641ae9a60fdbb4ce)
For EventsRegisterTest that test updates to streams and
subscriptions, we now validate the events generated by
the actions under test conform to predicted schemas.
We define the schemas with help from the validators code
that is also sometimes used to validate incoming request
parameters for our views.
(imported from commit b4222b920a588e15cccee4a2349c074ca9697448)
We now use the same custom matcher for all of our EventRegisterTest
tests. The "state" that we're tracking has three lists that aren't
really order sensitive, so we turn them into dictionaries keyed
by the primary keys in their structs. Here are the lists:
realm_users
subscriptions
unsubscribed
(imported from commit 53787c56722b69640368c1b5d67d5d4757f84718)
We had a couple tests in EventsRegisterTest that weren't really
testing much, because they were going through codepaths with
authentication problems or actions that didn't affect our
user. We now assert that the code under test generates
events.
(imported from commit c2f61180cb420d45fa95e137433e9456394bf0ff)
This change also makes it so that the test_rename_stream()
test exercises the code path. We need to subscribe the user
to the stream in order to generate events.
(imported from commit 77f965efbf5a766eb8de23486e303fa135b2e638)
Before this change, the test_pointer_events test wasn't really
testing anything, because it wasn't getting to do_update_pointer
due to authentication issues and having an invalid message id.
Calling do_update_pointer() directly exercises the events code.
(imported from commit bfac27dcfe659689535f54e0c837427c4f9a8284)
Add try/catch blocks to get_updates_success and send a blueslip error on
errors we catch. This will let get_updates_success return successfully
so that the next call to get_updates will start immediately.
(imported from commit 44d8b85d9d8e930a5552a5fbf4af1d0e5e8c07e8)
Add a helper to patch_global to change a global and then reset it to the
original value after a test file is complete.
(imported from commit 1b65ff6ea8693ad61b7f18f35dafa942429252a8)
This implementation is somewhat hackish in large part because I think
we're going to be wanting to redo the get_old_messages API somewhat
soon, and this may naturally become a lot cleaner as a result, but
this isn't a lot of code and fixes#2235 part (A) and substantially
mitigates #1510.
(imported from commit 47a2160a44befa9d83190c5cc95b90e92cc5b4cc)
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)
Before this change, we were doing assertNotIn to verify that Cordelia
was not among our subscribers after calling /json/subscriptions/remove,
but we were then catching the AssertionError except for every case. We
really only want to bypass the assertion when the server had reported
an error.
(imported from commit 0bdaf23047b795721372251724228daf18677df5)
This helps our iOS app when authenticating via Google Apps, since we
don't get the users' email address when we get the ID token from Google.
(imported from commit 066639958c1e8f7845505ebdabc37282defca5c5)
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)
Steve Howell
Luke Faraone
Leo Franchi
Zev Benjamin
Jason Michalski
acrefoot
Jessica McKellar
Tim Abbott