Earlier, the primary modal button always turned grey on being disabled,
while other modal buttons remained as is in light mode, and grey in dark
mode. Now the styling is made consistent across all modal buttons, by
giving them all 50% opacity when disabled.
So far, the Send buttons area would turn grey when the message could not
be sent. The Save button when editing a message would also turn grey
when the message could not be edited anymore. Now we simply make the
buttons half opaque instead of turning them grey in a disabled state.
We change the background colors for the close / cancel / exit buttons
in modals and messages (when editing them or viewing their source). The
border is also removed for those buttons in messages.
When viewing the source of a message when not editable, the opacity of
the read-only textarea would be reduced to 0.5, like for any other read-
only textarea in dark mode. This was unnecessary for viewing message
source, so the opacity for this case is now set to 1.
Fixes: #28701.
In spectator mode, the separators encapsulating the topic visibility
switcher wasn't being hidden since the `hidden-for-spectators` class
was being applied only to the `popover-menu-inner-list-item` element.
As a follow-up commit to c3e4358, this removes the additional
separator by shifting the `hidden-for-spectators` class to the
`popover-menu-outer-list-item` element instead, which is responsible
for showing the separators.
We could have added a new function that would return early on the
first property that changed instead of using
`populate_data_for_request`. But we would still need to fetch
`field_data` in most cases. Using `populate_data_for_request` will
keep things simple and readable while the performance difference
should be negligible.
Fixes#29750.
- We introduced an argument called `custom_profile_field` similar to
`sub` and `group` in `check_property_changed` and
`populate_data_for_request`.
- We could've introduced `field` param in `get_input_element_value`,
but I've kept it clean since it didn't have any similar kind of data input.
The performance difference due to this should be negligible.
- Introduced a span that would be parent to all `field_data` params
since it is needed by the diff infrastructure.
- If there is no data to be changed, we display our success status
without sending the PATCH request since save changed button is
always enabled.
This is a preparatory refactor since we need to use this function in
settings_components.ts which is a typescript file. Although the
original file seemed like the best destination for this function,
settings_components.ts seems like the second best destination.
Do not send unnecessary extra params when changing the value of
`required` field. Instead of searching realm.custom_profile_fields
for the field we are editing, we will just use the checkbox value to update
the field value, since we don't need to send other params like `name`,
`hint`, etc. to the API after API feature level 252 update.
Do not send unnecessary extra params when changing the value of
display_in_profile_summary. Instead of searching realm.custom_profile_fields
for the field we are editing, we will just use the checkbox value to update
the field value, since we don't need to send other params like `name`,
`hint`, etc. to the API after API feature level 252 update.
Following the topic sidebar action popover menu redesign using the new
"popover-menu" tippy theme, we update the icons of the menu options to
match the new UI.
Fixes part of #28699.
Following the stream sidebar action popover menu redesign using the new
"popover-menu" tippy theme, we update the icons of the menu options to
match the new UI.
`callback_after_render` was not being called when `render` did
an early return which caused "load more" to not be updated.
This is noticeable now since we are doing fewer calls to
`process_messages` which also updates the `load more` banner.
In narrow.activate, the adjusted_terms_if_moved helper uses the
raw terms from the URL for checking if a message was moved. If a
non-canoncial operator was in the URL for a narrow (e.g. "subject"
instead of "topic" and now "stream" instead of "channel"), then
the view wasn't updated correctly.
Update adjusted_terms_if_moved to use the canonical version of the
operator in the URL when adjusting the message history.
On creating a stream, instead of being redirected to the topic
`stream events` of the newly created stream, the user is only
redirected to the newly created stream, to avoid translation
issues with this topic name. The topic `stream events`
will not be present if the realm language is not English.
Important changes in this commit:
* We only cache message list for "Combined feed" if it is the
default view.
* We modify existing handling of home message list code so that
it can be used to for any message list that we want to cache
using a new `preserve_rendered_state` variable.
* narrow_state.filter() returns the filter of combined feed view list
instead of `undefined`.
* We start fetching messages from the latest message on app load.
* Messages in all messages data and Recent view are always synced.
* If combined feed view list is not cached, we don't track it's
last pointer, effectively sending user to the latest unread
message always .
Now we retry 3 times with 10s delays before giving up if on loading
the emoji. Hopefully user will just refresh the page by that time
if the emojis still can't be displayed.
Previously, the stream permissions warning banner failed to hide
after changes to the stream's privacy settings were saved or discarded.
This fix addresses the issue, ensuring the banner behaves as expected
by disappearing when changes to make the stream private are either
saved or discarded.
Fixes: #29625.
Change compose_reply_button tooltip logic to show the correct tooltip.
Earlier in organizations where DMs were disabled, a stale tooltip was
being displayed.
Earlier if the user hovered over the compose_reply_button when it was
disabled and switched to a stream in which it was enabled before waiting
for the tooltip delay, the next time the user hovers over the
compose_reply_button the stale disabled tooltip is displayed instead of
the enabled one.
This is fixed by checking if the compose_reply_button is enabled on the
fly while rendering the tooltip via instance.setContent().
Fixes#29238.
Mateusz Mandera
Aman Agrawal
N-Shar-ma
Sayam Samal
Shubham Padia
nimishmedatwal
Karl Stolley
Lauryn Menard
Kislay Verma
Anders Kaseorg
Akarsh Jain
Pratik
CIC4DA
Kenneth Rodrigues