Since the "mute users" feature isn't complete yet,
this UI is shown only in development setups.
Ideally we should have had this commit after the whole
feature was completed and merged, but doing so makes it
difficult to test and merge subparts of the feature one by
one (which is a better workflow, while we still decide what
exactly we want this feature to do).
This commit adds a new button in the user info popover
to mute or unmute the user, and uses a confirmation
dialog while muting, because muting a user accidently can lead
to the muter losing out on a lot of information.
TODOs when making this UI visible in production-
1. Make a /help page and link to it from the confirmation
dialog and the API docs.
This extra commit adds support for creating user group pills
in cases that do not use typeahead like, pasting the group
name, copying it from the user group pill.
This completes the remaining work required to support
addition of all members of a user groups to stream.
Fixes#15186.
We update the pills typeahead logic to also include user group
results and pass the "user_group" key in `opts` to enable this
option for Add subscriber form.
The changes includes:
* Exporting the `query_matches_name_description` function, to
deduplicate the typeahead `matcher` logic.
* Creating a `people.is_known_user` function, to deduplicate
the typeahead `sorter` logic.
* Add a new `user_group_pill.js`, to allow adding user group
pills in input widgets that support pills.
This has been tested manually as well as by adding some new
node tests.
This commit removes`typeahead_helper.sort_recipientbox_typeahead`
which was introduced in 639ec9380a
for the private message recipient box when it used to accept comma
separated text input for recipients. All it doew was cleaning away
invalid recipients from string, like:
"a, , b" was cleaned to [a, b].
This can be now removed because it was now used only in
pill_typeahead.setup code path, and the pills code already handles
invalid cases by filtering out all falsy (invalid) recipients.
We move compose.html to compose.hbs file while keeping
`#compose` still in `home.html` as a hanger
where append rest of the elements.
This will provide us with two benefits:
* We could share common elements between message_edit_form and
compose.
* We can insert compose directly in any element. We may decide to
do it for recent topics.
Adds a setting UI to list all configured playgrounds
in a realm. The filter functionality can be used to
search playgrounds by its name or language.
Default sort is provided on the 'pygments_language'
field.
Front tests added to maintain server_event_dispatch
coverage. The `settings_playgrounds.js` file is added
to coverage exclusion list since it is majorly UI
based and will be tested using puppeteer tests (in
following commits).
To prevent breaking of the hardcoded playgrounds, we resort
to checking if realm_playgrounds is empty and falling back
to the hard-coded list if so. This logic is removed in the
followup commit which introduces the UI to add a playground.
This is in preparation for moving this code to @zulip/shared for use in
the mobile app, where we will want to use Sentry for reporting errors,
rather than blueslip.
The way I've done this only allows for reporting one type of error
(currently, blueslip.warn), but seeing as we only have one place we
report an error, that seems like something we can fix if we want more
error levels at a later date.
This reduces the complexity of our dependency graph.
It also makes sub_store.get parallel to message_store.get.
For both you pass in the relevant id to get the
full validated object.
This breaks an indirect dependency of stream_data
on the channel module.
It's a verbatim code move, apart from the one-line
helper `has_history_for`. It's not totally clear
to me why the original code doesn't call into
`is_complete_for_stream_id` to early-exit, but
figuring that out is outside the scope of my
change.
It's possible that we will eventually just subsume
this tiny module into topic_list once we finish
breaking all dependencies, but we may want to
reuse this for something like Recent Topics
or other similar UIs.
It's also possible that we'll want to rename
stream_topic_history -> stream_topic_history_data
sometime soon, possibly after we clean up its
dependency on message_util soon.
We only update the `.private_messages_header` here since
unread_counts of `.expanded_private_message` are updated
via `pm_list.update_private_messages`.
This fixes the bug of PMs in `.expanded_private_message` having
the same unread count as `private_messages_header`.
Since we rerender the DOM of `.expanded_private_message` every
time we update unread count of PMs, we don't need to manually
update them here. Also, we always keep them on display since
there is no real need to toggle them. They are not visible
when they have 0 unread counts via `.zero_count`.
While rest of the app has ported to the new system of updating
unread_counts `activity` was not ported. This resulted in
unread count in buddy list not being updated when new
PMs arrive.
The series of commits to consolidate CSS classes
for the various unread-count spans across our app
created a bug where the stream_list.js code's selector
starting capturing the unread spans in topic list items.
Suppose you had a stream with these topics:
Foo 10
a 3
b 3
c 4
If another unread came in, you would briefly see:
Foo 11
a 11
b 11
c 11
Now we just use subscription_block to find the
element that we want to tweak.
I remove a convoluted node test here. Part of the
reason the node test was convoluted was that the
original implementation was overly complex. I will
try to re-introduce a simpler test soon, but this
is a bit of an emergency fix.
This reduces our dependency on message_list code (via
message_util), and it makes moving streams/topics and
deleting messages more performant.
For every single message that was being updated or
deleted, the previous code was basically re-computing
lots of things, including having to iterate through
every message in memory to find the messages matching
your topic.
Now everything basically happens in O(1) time.
The only O(N) computation is that we now lazily
re-compute the max message id every time you need it
for typeahead logic, and then we cache it for
subsequent use. The N here is the number of messages
that the particular sender has sent to the particular
stream/topic combination, so it should always be quite
small, except for certain spammy bots.
Once the max has been calculated, the common operation
of adding a message doesn't invalidate our cached
value. We only invalidate the cache on deletes.
The main change that we make here from a data
standpoint is that we just keep track of all
message_ids for all senders. The storage overhead here
should be negligible. By keeping track of our own
messages, we don't have to punt to other code for
update/delete situations.
There is similar code in recent_topics that I think can
be improved in similar ways, and it would allow us to
eliminate functions like this one:
export function get_messages_in_topic(stream_id, topic) {
return message_list.all
.all_messages()
.filter(
(x) =>
x.type === "stream" &&
x.stream_id === stream_id &&
x.topic.toLowerCase() === topic.toLowerCase(),
);
}
In an effort to use a common class to display unread counts across
the app, we simplify the elements used to show unreads and use a
single `span` with `unread_count` class to do so.
This commit replaces the "echo_data.orig_raw_content" with
"echo_data.raw_content" in "message_edit.js". If the user is editing
a message and it fails, all the edited data used to get lost. Now, the
new edited content appears so that the user does not lose his edited
content.
This bug has been present since the original #12145, where a
refactoring error resulted in using the pre-edit data.
Fixes#18142.
If you have two emojis of the same name, we were
trying to render the non-realm emoji without an
emoji_code, since the condition that I changed
here was erroneously just seeing if the name was
among the realm emojis.
This fix prevents a funny symptom that is reported
in #18135. The symptom is that the non-realm
emoji causes us to render the top-left emoji in
our sprite sheet, since we didn't put emoji_code
into the args.
This doesn't fix the fundamental problem that
having two emojis of the same name is extemely
confusing. Our markdown parser obviously can't
distinguish ":thank_you:" from ":thank_you:". For
the the typeahead case I suppose we could add some
kind of suffix.
So, this fix only simplifies debugging; it doesn't
get to the root of the problem.
KaTeX makes use of a "span.overlay" element for the little vector
arrow symbol on top of a `\vec` object. This conflicts with Zulip's
CSS for our overlays, which are divs with the `overlay` CSS class.
While KaTeX may rename their class
(https://github.com/KaTeX/KaTeX/issues/1456), we can work around this
issue by scoping our own overlay CSS and click handlers to
"div.overlay" rather than ".overlay".
Fixes#18068.
This commit adds a helper function named `handle_linkifier_api_error`
to `static/js/settings_linkifiers.js`. As the name suggests, this
function handles the error returned from the API, specifically
for operations on linkifiers (like adding linkifier).
This is a prep commit for `Add setting to edit linkifiers`.
Related issue: #10830.
The main motive to add this helper function is to avoid copying
substantial blocks of code, as it tends to result in someone later
fixing bugs in only one of the two places.
Abhijeet Prasad Bodas
Mateusz Mandera
Sumanth V Rao
m-e-l-u-h-a-n
ryanreh99
Aman Agrawal
Wesley Aptekar-Cassels
Steve Howell
Anders Kaseorg
Signior-X
Tim Abbott
akshatdalton