This change is long overdue. After implementing this much more robust
system and deploying it on chat.zulip.org, we hesitated to make
load_server_counts the default behavior in master, because of data
anomalies present for many existing users (basically messages far back
in their history that they had never read, on streams they believed
themselves caught up on), which would have been confusing for many
users.
However, because the mobile apps have been using this data set for a
long time, we've likely cleared out the anomalies from active users'
data set. And for older users, they're going to come back to
approximately infinite unread messages anyway, so the data anomalies
are unlikely to be important.
Fixes#7096.
This commit prepares the frontend code to be consumed by webpack.
It is a hack: In theory, modules should be declaring and importing the
modules they depend on and the globals they expose directly.
However, that requires significant per-module work, which we don't
really want to block moving our toolchain to webpack on.
So we expose the modules by setting window.varName = varName; as
needed in the js files.
Despite a few warts, we are going forward with getting topic
history from the server when you click "more topics." This
commit simplifies the code by removing the feature flag
checks.
This reverts commit c953759486.
The client side logic for dealing with server counts is actually
fine, as far as we know, but there are still some data-related
issues with cleaning up old unread counts.
The server sends down lists of unread message ids in various
buckets, and we now use those on the client to provide more
complete counts of unread messages.
With this flag turned on, all streams will have a "more topics"
link, and clicking that link will always fetch topics from the
server to show a complete list of topics that you have had messages
for on that stream.
Note that if you only recently joined a public stream, your list
of topics won't go back to before you joined the stream, even though
that content is searchable. We may change that in the future, but
we will need to be careful about spamming folks who frequently
unsubscribe from streams.
This commit removes all references to feature_flags.local_echo.
It's been a core feature for about four years, so I think we
can safely say the experiment was successful.:)
We had never-enabled code to allow users to set default
streams for their bots (for event registration, default sending, etc.).
This commit removes the code.
Zulip's logic for garbage-collecting data structures before reloading
was a fix for a Chrome memory leak that lasted across reloads a few
years ago. That memory leak is probably now fixed, and thus logic is
causing lots of JavaScript tracebacks that are probably not useful.
So, let's try removing this cleanup logic (everything but the
still-useful deletion of the event queue).
This can be useful in scenarios where the network doesn't support
websockets. We don't include it in prod_settings_template.py since
it's a very rare setting to need.
Fixes#1528.
This is controlled through the admin tab and a new field in the Realms
table. This mirrors the behavior of the old hardcoded setting
feature_flags.disable_message_editing. Partially resolves#903.
CUSTOMER16 wants their employee realm to:
* only use JWT logins
* have name changes be disabled (they want users' full names to be the
their CUSTOMER16 user name).
* not show the suggestion that users download the desktop app
(imported from commit cb5f72c993ddc26132ce50165bb68c3000276de0)
This fixes#730, which includes any customers we want to notify
about the feature being pushed.
(imported from commit c60959ddd7c61ea8e014e984047e9f7bc0d59296)
This experiment has been disabled for everyone for a while: if we
bring something like this back, it is not likely to be exactly the same,
and will be different enough to require a different implementation.
As it is, the summarization code was making a few code paths (rendering
especially) more complex, and is worth removing for simplicity's sake.
(imported from commit 6ac8cdc9f7077a5a1da01ab4268aba3db0bc43f8)
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)
Tim Abbott
Steve Howell
Armaan Ahluwalia
Aditya Bansal
Steve Howell
Rafid Aslam
Zac Pullar-Strecker
Tim Abbott
Rishi Gupta
Tim Abbott
David Roe
Kate Buckner
Reid Barton
Anders Kaseorg
Waseem Daher
Zev Benjamin
Jason Michalski
Steve Howell
Leo Franchi
Jessica McKellar