This commit addresses the issue of relying on `compose_state` for
retrieving the `stream_id` to display warning banners. Previously,
warnings were shown for syntax in the message edit box based on
whether that syntax would trigger a warning for the draft content (if
any) currently in the compose box.
We fix this by using a new `get_stream_id_for_textarea` function to
obtain the correct `stream_id` value for the check being done.
Fixes: #25410.
When there are only muted unread mentions in a stream, show `@` icon
and unread count in faded style, also align the `@` on more topics
with no unead counter on it.
If there are only muted unread messages without mentions don't show
the unread counter on the stream.
Fixes#25382.
We need to append the `version` parameter when constructing the urls for
medium-sized images so that the browser updates the image in real time when
the user uploads a new avatar.
Fixes#25558.
This commit updates the Help Center links in all relevant empty message
list views to open in a new tab by default. This prevents users from being
navigated away from the app.
Fixes#25337.
This commit moves `maybe_get_stream_name` function from `stream_data` to `sub_store`
as it didn't had any dependency on `stream_data` and it also helps us to cut off
dependency on `stream_data` for some of the modules including `user_topics`.
This removes the previous "or forward" text from the message
actions popover, and keeps the documentation in sync with the
new text. Internationalization tests are updated, too.
Fixes#25603.
Prior this commit, changing the message type from a stream (where posting
was not allowed) to a direct message using the compose box dropdown, did not
changed the state of the send button from disabled to enabled even though
direct messages were allowed in the organization.
This was happening because `check_stream_posting_policy_for_compose_box` was
only for streams.
Now, function is updated to check for both streams and direct
messages, as it checks if direct messages are allowed or not, and depending on
that, it updates the send button's state, tooltip and displays a relevant banner.
This likely needs further refactoring to switch to using stream IDs
rather than names in this code path, but this change fixes an
exception that would be throw when opening the compose box while
viewing a narrow to an invalid stream name/ID.
Keyboard navigation has been added to the scheduled messages modal
in this commit. The solution is based on the `modals_handle_events`
function from the `messages_overlay_ui.js` module, as well as some
helpful functions from the same module.
Fixes: #25181.
This is a preparatory commit to implement keyboard navigation in the
message scheduling modal. The main goal is to make the
`modals_handle_events` function reusable. To achieve this, we have
extracted all the context-related variables and replaced all
mentions of "draft" with the more neutral term "item". The
`modals_handle_events` function now also has a context parameter,
which contains all the necessary methods and properties to work in
different modal contexts.
This changes to not report any `call POST /json/users/me/presence`
spans, which we previously reported despite not including the inner
auto-instrumented HTTP spans.
Previously, when a user enters a empty dm-including view, they'll notice
the "Why not start the conversation" action line and click on the link.
When this happens, the compose box would open but the receipent box is
never populated.
Since the dm-including view is a search view, we should drop that phrase
from dm-including views altogether. It also isn't super natural to
have a button that starts the conversation with the user anyways.
Fixes: #25524.
`update_or_append_banner` abstracts the logic for not creating another compose
banner if one is already present in the DOM, it just replaces the content of the
old banner with the new one.
This commit introduces a new container parameter for functions that
can be used for both compose and edit mode. It provides the function
with information about the context in which it is being used.
This introduces a function that checks for both the existence and the
expiration of the `selected_send_later_timestamp`.
The logic it supports prevents users from scheduling a message to send
in the past or less than five minutes into the future at the level of
the UI (specifically the popover on the \vdots component of the Send
button). That can happen if a user attempts to edit a previously
scheduled message.
Fixes#25439.
In the "mentions" test, an additional unread message with the type
"private" and directly mentioning me has been added. This test case
checks for the scenario when the stream_id is null during the
reverse_lookup, which would have caused the test to fail before the
bug fix was implemented which now passes after the fix is applied.
This commit ensures that user-locale and 24-hour preferences are
respected in the message-scheduling modal. It also simplifies the
translation of text strings in the scheduling modal.
Available scheduling options and their time values, including whether
the options are allowed, are now calculated every time a user opens
the scheduling modal.
In order to achieve those things, additional interrelated fixes here
accomplish the following:
1. Modal-scheduling opts now have data- attributes containing
timestamps for the time a message will be scheduled to send.
2. With those timestamps in place, the logic for setting the
scheduled send-time is simplified.
3. There are no more `send_later_xxx` global variables in the
`schedule_send` module.
Fixes#25403.
This commit extracts date-based logic from the popover menu file and
puts it in with the scheduled-messages logic.
The aim is for greater testability, with some initial tests now
presented on the date-based logic.
This function will allow us to adjust the codebase to write what it
means semantically -- whether a check is for the message list being
visibly empty, or completely empty.
In this commit, we leave the .empty() method incorrect, because
several other adjustments need to be made atomically with fixing it.
Apparently some past refactor caused the animation for new mentions to
be triggered when initialization the app.
(This seems pretty clearly unintentional: A user loading the app
doesn't need their attention specifically drawn to the @-mentions view
in the same way that a user who is using the app and receives a
mention right now does.)
Fixes#24641
When the user clicks on a link which has `stopPropagation`
and doesn't trigger `scroll`, then we don't hide any existing
popovers if the element being clicked doesn't hide popovers
explicitly.
To fix this, we hide all popovers on change in hash which makes sense
on its own given how we use hashes.
This commit introduces structures and logic to hide the Scheduled
messages item from the left sidebar if there are no messages
scheduled to be sent.
Test coverage has been added for counts and visibility, too.
Fixes: #25101
This commit introduces logic to present a message count with the
Scheduled messages item in the left sidebar.
The count is present on the initial load, and is updated as a user
adds or removes scheduled messages.
Previously, the unread banner templates just rendered on the contents of
the unread banner. This works fine if we don't want to make changes towards
the parent/container of the contents.
This change introduces a new container to each unread banner templates and
a rename. Thus, we can make unique styling changes to the unread banners
while also bring the structure closer to how it is for compose banners.
This commit deletes `/fixed-width` and `/fluid-width` slash commands
from the typeahead and also hides the slash commands `/light` and
`/dark` in production.
Fixes#25374.
When all the unread messages in a muted stream are in specifically
muted topics, this ensures that the total unread count for the stream
that the user sees before clicking "more topics" will match the total
unreads number for the stream itself.
This behavior is limited to muted streams, since in a normal / not
muted stream, we don't display a "muted topics only" faded unread
count by the stream's summary line to avoid distracting the user with
it, we match that behavior for the "more topics" line.
We also now display the `@` , again to ensure the stream's summary
line never displays an `@` without some topic row having one.
Earlier, the `s` hotkey just narrowed to the stream of the selected
message (to a topic), while `shift+s` narrowed to the conversation view
(topic / dm) of the selected message.
Now, the `shift+s` hotkey has been removed (but retained for toggling
subscription to a stream when the stream overlay is active), and the `s`
hotkey takes on double duty: if the current view is not topic / dm, it
narrows to that, else when in topic view, it switches to stream view. It
has no effect when in dm view. Documentation has been updated for this
both in the help center, and the in-app `Keyboard shortcuts` menu.
A deprecation notice has been added for `shift+s` as well.
Fixes: #24226.
Aman Agrawal
Daniil Fadeev
sbansal1999
Hardik Dharmani
Lalit
Akarsh Jain
Karl Stolley
Brijmohan Siyag
Tim Abbott
Alex Vandiver
Joelute
evykassirer
N-Shar-ma