Fixes#25340
This means that we now schedule the message simply after selecting
time if the message is valid.
Also, editing scheduled messages will now delete the scheduled
message and open compose with scheduled message.
The server will probably accept them and just send the message
immediately, which seems OK, but we probably want to discourage
scheduling a message to be sent in the past, since that's unlikely to
be intentional and would make it hard to undo.
This introduces a 'Custom time' link to the bottom of the scheduling
modal's options. Clicking on it pulls up the date picker.
Additionally, clicking on the 'Custom time' link, then clicking
elsewhere to close the time-picker, then subsequently clicking
'Custom time' again reveals the time-picker.
However, repeatedly clicking the 'Custom time' link while the
date-picker is already open will cause the date-picker to redraw
each time.
Previously, when a user scrolls down a long text of message and presses
the hotkey for viewing the message actions, the popover menu would continue
to open where the message actions button. Thus, the popover menu would be
cut short and sometimes off the screen. These changes will scroll the
client to the top of the message and ensure that the popover menu is
always visible.
Fixes: #23774.
This commit adds "Rename topic" option in topic sidebar popover
which will be shown when user is only allowed to edit topics and
not streams.
Note that we still cannot show or hide the option as per the time
limit setting (since client may not have the first message of the
topic locally), so we just show or hide it as per
move_messages_within_stream_policy setting.
Fixes#19886.
This commits changes the placement of "Add streams" tooltip
and "Filter streams" tooltip to "bottom" when the
"Add streams" popover menu is opened and changes its back
to "top" when the popover menu is closed.
It makes use of the "id" attribute that has been assigned
to those tooltips in commit 01e6121e5a.
Fixes: #20675.
Updated topics_sidebar_actions.hbs to include a option to add/remove
unmute visibility_policy for a topic is in a muted stream,
if in development environment.
Added 2 new classes sidebar-popover-unmute-topic and
sidebar-popover-remove-unmute for unmute topic option. Also, Renamed
previous sidebar-popover-unmute-topic to sidebar-popover-remove-mute.
Added 4 new click handlersthat uses
user_topics.set_user_topic_visibility_policy() to update
topic's visibility_policy.
Fixes#24244
This commit refactors the topic_menu visible check and hide logic,
since we have already migrated the popover from stream_popover.js.
This last bit of code related to topic_menu is also migrated to
popover_menus.js, and the code is refactored to use the new logic,
which is more common for the popover_menus.js system.
To hide the popover, one possible solution could be to use the
hideAll method from TippyJS. However, this could lead to
unintentional behavior for all the popovers. To prevent this, the
hide method is used for the topic_menu only.
This commit migrates the topic_menu popover from stream_popover.js
to popover_menus.js. Since the data required for rendering is large,
it has been moved inside popover_menus_data.js to improve code
readability.
Getting the link of the topic for the clipboardJS inside the onMount
instance was not working with the existing method. To make it easier
to work with, a new attribute, data-clipboard-text, is added to the
'Copy link to topic' anchor tag. This allows the clipboardJS to catch
the URL. The value of data-clipboard-text is sent from popover_menus.js
to the topic_sidebar_actions template.
Fixes: #23891
Changed the `.enter_sends` css selector for launching tippyjs popover from
`compose.hbs` because it was colliding with `.enter_sends` selector present in
`organization_user_settings_defaults.hbs`.
Before this change when an admin tried to change user realm default setting of
`enter_sends` it was opening a tippyjs popover despite being a checkbox and it
was hitting `/json/settings` endpoint instead of `/json/realm/user_setting_defaults`.
Ever since we started bundling the app with webpack, there’s been less
and less overlap between our ‘static’ directory (files belonging to
the frontend app) and Django’s interpretation of the ‘static’
directory (files served directly to the web).
Split the app out to its own ‘web’ directory outside of ‘static’, and
remove all the custom collectstatic --ignore rules. This makes it
much clearer what’s actually being served to the web, and what’s being
bundled by webpack. It also shrinks the release tarball by 3%.
Signed-off-by: Anders Kaseorg <anders@zulip.com>