This finishes up the work from 057ee6633a.
We had this "get_reload_topic" helper for user that has "topic"
encoded as "subject" from a older release. This is unlikely to cause
problem now because we no longer use "subject" for reloading since 2018.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This removes the temporary get_draft_topic helper from utils and remove
references to draft.subject.
This finishes up the work from
9861cdfeb6. Since 2018 we had stopped
referring to the "subject" property, it is considered safe to remove
this code now. It's impossible to directly upgrade to the current
release without substantial downtime for upgrading the OS, so this
logic is unlikely to provide any future benefit.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
Uptil now only space was used as a word separating character when
searching streams. This meant that searching for "xyz" would not turn
up a stream named "stream-xyz" as one would expect.
Since -, _ and / are likely to be used as word separators in stream
names, these 3 are added as word separators for streams. The utility
function `filter_by_word_prefix_match` is refactored by adding an
optional `word_separator_regex` argument.
Fixes: #19700.
This commit adds a tippy tooltip for inline image previews in messages.
There exists some (reasonable) logic in `static/js/util.js` which
overrides all title attributes for links to user-uploaded content to
ensure they always display "Download <filename>". This doesn't make
sense for inline images specifically because they will be opened in a
ligthbox, so we prevent that.
There is an additional tippy instance created in `static/js/tippyjs.js`
to add tippy tooltips to inline images, which takes advantage of the now
preserved title attribute of the parent link.
Creates a helper function in `message_edit.js` that loops over
a message's edit history to see if a stream and topic pair
existed at some point in the message history.
Exports `util.lower_same` function to use for comparing
edit history topics as lowercase.
Also adds test for new function in `mesage_edit` node tests.
In this case, for TypeScript narrowing to work correctly, we need
a if statement that check that both of the type are same. The one
condition we had that checked that both have the same type doesn't
work with TypeScript narrowing yet.
We use a Symbol for unassigned_value_sentinel and explictly assign
the compute_value property instead of using Object.assign. Both of
these are needed to type annotate it easily.
This is done so that it can be shared by more generally
by different filter widgets used in web-app. An extra parameter
is added to it that helps to get text representation of of items
to be sorted, as items passed to it could be of different format.
ES and TypeScript modules are strict by default and don’t need this
directive. ESLint will remind us to add it to new CommonJS files and
remove it from ES and TypeScript modules.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Prettier would do this anyway, but it’s separated out for a more
reviewable diff. Generated by ESLint.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This commit changes the would_receive_message to use user_id
instead of emails.
This change is done because user_ids are immutable and using
user_ids is the correct way of uniquely identifying user.
The change in 'would_receive_message' also leads to change
in util.is_pm_recipient to use a string of user_ids instead
of emails.
We also know that user_ids passed to 'would_receive_message'
are active user_ids, since we get them from buddy_list.
So we don't need to check whether the user is active, which
was previously being checked by get_active_user_for_email.
While we could fix this issue by changing the markdown processor,
doing so is not a robust solution, because even a momentary bug in the
markdown processor could allow cached messages that do not follow our
security policy.
This change ensures that even if our markdown processor has bugs that
result in rendered content that does not properly follow our policy of
using rel="noopener noreferrer" on links, we'll still do something
reasonable.
Co-authored-by: Tim Abbott <tabbott@zulipchat.com>
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
This is not always a behavior-preserving translation: _.extend mutates
its first argument. However, the code does not always appear to have
been written to expect that.
Signed-off-by: Anders Kaseorg <anders@zulipchat.com>
These functions were just shims that were
used in the somewhat painful migration from
subject_* to topic_*.
The commit 4572be8c27
fixed it so that the client never needs to
deal with "subject_links".
So now we just go back to simpler code:
message.topic_links = links
links = message.topic_links
I am not quite ready to declare victory on
the subject/topic migration, but we are super
close. In this commit I bump a blueslip
warning to a blueslip error, so that we'll
be notified of any codepath that is still
using the janky fall-back-to-subject defensive
code here.
If we go a couple days without any errors, then
we can remove the blueslip warning and the
defensive code immediately and then inline
the callers at our leisure. I wouldn't be
wildly against keeping these wrappers in some
parts of the code, but that debate is out of
the scope of this immediate fix, and I haven't
thought hard about it yet.
We can basically sweep set_message_topic() now,
if we wanted to, since it's truly just a one-liner.
(At one point it was encapsulating something
like `message.subject = foo`).
This required a tiny change to compose_fade
test setup.
I am 99% sure we can rely on trimRight() and
trim() being available in all browsers that
we support. I verified in FF.
This removes the util dependency from both
modules touched here.
We now treat util like a leaf module and
use "require" to import it everywhere it's used.
An earlier version of this commit moved
util into our "shared" library, but we
decided to wait on that. Once we're ready
to do that, we should only need to do a
simple search/replace on various
require/zrequire statements plus a small
tweak to one of the custom linter checks.
It turns out we don't really need util.js
for our most immediate code-sharing goal,
which is to reuse our markdown code on
mobile. There's a little bit of cleanup
still remaining to break the dependency,
but it's minor.
The util module still calls the global
blueslip module in one place, but that
code is about to be removed in the next
few commits.
I am pretty confident that once we start
sharing things like the typeahead code
more aggressively, we'll start having
dependencies on util. The module is barely
more than 300 lines long, so we'll probably
just move the whole thing into shared
rather than break it apart. Also, we
can continue to nibble away at the
cruftier parts of the module.
Zixuan James Li
N-Shar-ma
Austin Riba
Lauryn Menard
Tim Abbott
Anders Kaseorg
isakhagg
Priyank Patel
m-e-l-u-h-a-n
Anders Kaseorg
sahil839
shubhamgupta2956
Steve Howell