Previously, we used to do a kind of "local echo"
whenever the user muted/unmuted a topic. Meaning,
we used to do most of the UI update work before making
the API call to mute the topic, instead of after
receiving the `muted_topics` event. This behavior
has been so since the beginning of time
(b4b6fa14d3) and isn't ideal because:
1. If the request fails on the backend, the UI
could end up in an incorrect state.
2. Adds code complexity.
3. Makes it difficult to catch bugs related to
live-update (like the one fixed by
f725711ff2).
4. Isn't consistent with other parts of the
codebase, which do the UI update while handling
events.
This commit makes it so that all the UI update
work is done only after recieving the `muted_topics`
event.
The only possible issue with this strategy could
be users sending another duplicate request in the small
time span before receiving the event. But that isn't
a big problem, because all requests involved here are
idempotent, and the worst that can happen is a HTTP 400.
This commit adds support for a `None` option in the dropdown menu
of `Notification sound`. When this option is selected, no audible
notification is sent to the user.
`None` will appear as the first option in the dropdown menu, since
this is not categorized as a playable audio.
This new option is added so that folks can disable audio notifications
without losing their other notification configuration (like for PMs, mentions).
Necessary test case is added for this new option.
Fixes#16090.
Item field is added to the pill items, this is done to utilize
it wherever possible, to distinguish between diffrent types
of pill items(stream|user_groups|users).
It is also a preparatory commit to support expanding of stream
and user group pills.
Deduplicate control buttons by re-using the
compose_control_buttons.
A link to `help` overlay was added to `message_edit_form`
as a part of this process.
This fixes a bug that when video provider is set to `Jitsi`
from `none` in organization settings while message_edit_form
is open, the video icon is not displayed since
it was not present in the message_edit_form DOM even if
compose.update_video_chat_button_display tries to display it.
It is fixed since the `.video_link` element is always present
in DOM of `message_edit_form` now.
We convert the following elements to use a class instead of
id for accessing them across the codebase:
* markdown_preview
* undo_markdown_preview
* markdown_preview_spinner
* message_edit_content
* preview_content
Converted them together since changes to one impacted the other in
some modules like click_handlers.
Also, added a function in rows to get `message_row`.
We use `.compose_upload_file` across compose and message_edit_form
for file upload icon. This will help us share common code between
`compose` and `message_edit_form`.
In both compose and `message_edit_form` we use `file_input`
class to identify the file `input` element. This will help
to more easily share common elements between compose and message_edit.
Since we can have multiple instances of `message_edit_form`, it
makes sense to have it as a class.
We track the message_edit_form by setting an id to
`form` element dependent on message_id.
This commit makes it so that muted users never appear
in the right sidebar buddy list, filter text or not.
The hiding is done in the frontend only, and we still
recieve presence data from the server as before, so
no extra work is required on unmuting someone, other
than to rerender the user list.
Long term if we find that there are too many muted users,
we may want to optimize how we send presence data, but
that is unlikely to happen.
The other less extreme option is to gray out muted users,
but that cannot be done because it would conflict
with the graying out we do for non-recipients when the
compose box is open.
This makes the naming more intuitive and gives us a
single place to add more conditions on filtering
user_ids, with the current motivation being filtering
muted users, the logic for which will be added in further
commits.
This is a direct code move which puts all the functions
related to `user_id` lists near the bottom of the file.
This will make the file slightly easier to read.
Long labels like "Yes, Unsubscribe this stream" can
be confusing for translators and it can also create bad
strings that can end with like 4 long words in German.
It is better to have the simple options like "Confirm"
and "Cancel". This commit fixes this issue by changing
the text to "Confirm".
Fixes#17926.
Previously, realm emojis can override default emojis in emoji-picker,
if the user sets an exisitng emoji name to his/her custom emoji.
For clear understanding--
If a user sets an realm emoji with name `smile`, this leads to the
newly realm emoji override the existing default emoji `smile`.
To address such behaviour, Added a warning modal which requires
the user confirmation before overriding the default emoji.
Fixes#16913.
Moved `admin_user_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Fixes#18227
Moved `admin_user_group_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_tab` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_profile_field_list` template to `/templates/settings/` folder
as earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Also modified the node tests to reflect the new changes.
Moved `admin_linkifier_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_invites_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder instead.
Moved `admin_human_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_export_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
rather than the `/templates/settings` folder.
Moved `admin_emoji_list` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and should have been within the `/templates/settings` folder.
Moved `admin_default_stream_list` template to `/templates/settings/`
folder as earlier, it was inaccurately placed within the `/templates`
folder and should have been within the `/templates/settings` folder
instead.
Moved `admin_bot_form` template to `/templates/settings/` folder as
earlier, it was inaccurately placed within the `/templates` folder
and `settings` folder is specifically for storing administrative
UI templates.
This involves in two changes for styling.
1. The alert class is moved from alert.css to app_components.css as this
class serves nothing but to default .alert elements to be hidden. This
is only required in the webapp but not portico pages (where .alert
elements are preferred to be shown by default).
2. The import statement for alert.css is moved from app.js to common.js,
so that both the webapp and the portico pages can share the styles. This
will be fine to share the styles as .alert-display, .alert-animations,
.alert-box are more specific then .alert and they use nested class to
define styles for inner elements.
Undoes #17936 properly.
This improves the UX of creating a stream for atleast 1000+ users
realm by showing the the stream creation form much faster than
before.
Search, user addition, scrolling worked smoothly on 15k+
users realm as tested on dev setup.
Also, simplebar is used to replace the default scrollbar.
Fixes#16805
When moving a topic within a stream that is deactivated, the stream
may not be present in stream_data. Avoid throwing an exception in
this situation by leaving stream_name as undefined; existing logic
seems to anticipate that as a possibility, so we don't need a broader
change.
Longer term, we may want to just send to clients basic data about
archived streams that the user has access to.
Fixes: #17271
This commit adds a helper function: `mute_or_unmute_topic`
in `click_handlers.js` to mute and unmute a topic. This function
is called when a user mutes/unmutes a topic from its recipient bar
or `recent topics`.
This is a prep commit for `Allow unmuting of a topic from its recipient bar`.
Related issue: #15223.