Currently when hovering over the external link icon generated when a topic contains a
realm filter, an underline appears. This commit removes that underline.
static/ serves static files which get copied around per deploy. Since
the webpack stats files need a consistent name and change per deploy,
they can't live in static/.
This fixes a bug that preventing downgrading a Zulip server to an old
version.
This commit renames possibly_notify_new_messages_outside_viewport()
to the more concise name notify_local_mixes().
We really only need to call this function in one place, so we
have the caller check the `local_id` condition. We can eventually
upstream this code even further so that it's completely
obvious that it's only ever called from the local-echo codepath.
We were calling maybe_add_narrowed_messages() in a place
where local_id is guaranteed to be undefined, since
we always set local_id to undefined when
can_apply_locally() fails.
In turn maybe_add_narrowed_messages() was calling
possibly_notify_new_messages_outside_viewport(), which
requires a local_id to do anything meaningful.
This removes all the associated dead code--passing in
a parameter that we know always was undefined and
calling a function that we know always would no-op.
Not only does this simplify the code a bit, but it avoids
us stepping on the toes of the alternative code path that
deals with non-locally-echoed messages.
This commit early-exits before our loop when local_id is none,
and it tries to more clearly indicate that the callers will
generally be just calling this with messages sent on the
local-echo path.
We now make it so that get_next_local_id() only returns up
to 5 local ids relative to any given max id.
For example, if your pointer is at message 999, we'd give out
999.01, 999.02, ..., 999.05.
We also avoid giving out the same local id twice. This prevents
a bug where if you had aborted a previously failed locally echoed
message, a subsequent local echo would get into a funny state.
In order to to prevent false alarms on using the same local id
twice, we call get_next_local_id() later in the try_deliver_locally()
function.
We had code that would try to re-render locally echoed messages
that were rendered right before a browser restart. This code
has gotten buggy over time, so we are removing it for now.
We will try to re-solve the problem as part of #5825, but
possibly with a different strategy.
This fixes a performance issue that caused this migration to run for a
really long time.
It still takes about 1 minute to run with the 75K Subscription objects
we have on chat.zulip.org, but that's within the realm of acceptable.
This commit removes all code related to headers because
(1) we don't need the code and (2) it splits #**stream**
as a paragraph, which we don't want. This commit also
fixes the inconsistency when #**stream** is on a new line.
Fixes#4678.
This allow the webbpack dev server to properly reload JavaScript modules
while running in dev without restarting the server. We need to connect
to webpack-dev-server directly because SockJS doesn't support more than
one connection on the same host/port.
We eliminate `.get(0)` calls in buld_stream_list.
The easy case is that we stop building jQuery objects
for the splitters only to pull out the DOM immediately.
The more subtle case is that we also don't do `.get(0)` calls
to get DOM out of our individual list items. By passing
in full jQuery objects to `append()`, we should prevent ourself
from orphaning the old objects, which may in the future have
things like tooltip logic attached to them.
This is required, since we just reorganized the python-zulip-api
repository into 3 packages.
A nice side effect is that we get to eliminate some now-unnecessary
code for editing sys.path.
The user mention regex was checking for multiple lines,
so it broke when the user mention was on a new line.
This changes the regex AND adds a couple tests to
test inline markdown regexes.
Also adds Confirmation.type, and cleans up the rest of Confirmation to look
more like the model definitions in zerver.
In the migration, all existing confirmations adopt the type
USER_REGISTRATION, to be conservative. In a few commits, different
confirmation types will have different validity periods, and
USER_REGISTRATION will have the shortest default.
This hack saved a lot of time debugging weird issues back in 2016, but
it's no longer needed.
Anyone rebasing a branch from 2016 will need to provision afterwards
regardless, which will fix this issue automatically, and more
importantly, these changes were made obsolete when we moved to the
cached `node_modules` model.
In most cases, we do have the data for which other user was
responsible for subscribing the target user to new streams.
The main case where we don't is when the user is created and gets the
default streams.