We should not show UI for moving locally echoed or failed messages.
For the edit/move icon in message controls -
- After 2451002, we showed "Move message" icon for locally echoed
messages when moving messages was allowed as per org permissions.
This was clearly a bug and this commit fixes it and we instead
show "View source" icon.
For "m" hotkey -
- After 2451002, pressing "m" opened "Move messages" modal for
locally echoed messages when moving messages was allowed as per
org permissions. This was clearly a bug and this commit fixes it
and pressing "m" does nothing.
For pencil icon in recipient header -
- Previously, the pencil icon was showed even if first message
below the recipient bar was locally echoed and the topic edit
failed silently with locally echoed or failed messages again
showing under old topic after reload. This commit fixes it
to hide the icon in such cases. The original behavior was
that server returned an error with not so appropriate
response.
- Note that we can only check the first message below the header
since it will be inefficient to check all the messages whether
each of them is successfully sent.
And in such cases when any of the later messages is locally
echoed, the topic edit succeeds but the locally echoed or failed
messages are shown under old topic after reload.
- The behavior is same for the "checkmark" icon for resolving
topics in the header.
For three-dot message menu -
- We don't need to do anything here since the three-dot icon
is not shown for locally echoed or failed messages.
For the "Move topic" option in topic popover in left sidebar -
- We cannot do anything here since it will be inefficient
to check all messages in the topic whether they are locally
echoed or not everytime we open the popover.
- If the first message in topic is locally echoed or a failed
message, then the id of first message of the topic returned
from server is undefined and we see an error in client while
trying to get message from that id. And if one or multiple of
the later messages is locally echoed, then only successful and
server-acked messages are moved.
Note that this cannot handle all cases like a user can use
a successfully sent message to access the topic edit UI
and then choose "change_all" and "change_later" propagate
modes. In such cases the locally echoed and failed messages
will remain in the old topic only.
We do not allow sending messages where sending request had failed
or message is locally echoed. This commit extracts these checks
to a new function so that we can avoid duplicating code.
Previously, we allowed editing topic of "no topic" message, when other
conditions were not met, only from recipient bar but it is allowed
irrespective of other condtions. This commit fixes it to show the
"Move message" option and icon for "no topic" messages irrespective
of other conditions.
Previously, NO_LONGER type was just used to display
the text in the bottom-right of message edit form
which we have removed now, so we can remove `NO_LONGER`
type now.
Previously, we allow moving message (both topic and streams) in
the message edit UI and we opened message edit UI when clicked
on "Move message" option in message three-dot menu. Now, we open
the "Move topic" modal (that is opened when using "Move topic"
from topic sidebar) on clicking "Move message" option in
message three-dot menu.
We remove the hotkey "e" from "Move message" option for now since
both edit and move UIs are different now. We will instead add
new hotkey in further commits.
We pass stream_id as undefined when stream is not changed. This is
required for case when only topic editing is allowed. It worked
previously because we show "Move topic" option in left sidebar
only when stream editing is allowed.
We now allow only content edit in message_edit_form which can
be opened by pencil icon in the message row, "Edit message"
option in popover and by using e hotkey.
As a result of this change, we also do not show topic and stream
edit options when using "View source" options.
We would instead support changing stream and topic from the modal
which will be opened from the "Move message" option in message
actions popover.
Previously we did not send notification for topic-only edits.
Now, we add backend support for sending notification to topic-only
edits as well.
We would add support for this in webapp in further commits since
message edit UI will be updated as well. We just make sure that no
notifications are sent when editing topic using pencil icon in
message header.
We also change the API default for moving a topic to only notify the
new location, not the old one; this matches the current defaults in
the web UI.
Includes many tests.
We also update the puppeteer tests to test only content edit as
we are going to change the UI to not allow topic editing from
message edit UI. Also fixing the existing tests to pass while
doing topic edits is somewhat complex as notification message
is also sent to new topic by default.
Fixes#21712.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Previously, content box was focused inspite of it being disabled in case
when only stream editing was allowed. Now we instead focus on the stream
down.
Split the View source / Move message option into two menu options that
take you to the same UI: Move message and View message source.
Previously, it was confusing to have this double option,
and hard to parse it at a glance.
-View message source uses the current icon.
-Move message uses the arrows icon from the Move topic menu option.
-New option order: (1) Move message, (2) Quote and reply or forward,
(3) View message source.
Also remove the "Topic editing only" and "View source" text on the
bottom right of the message edit UI along with the tooltips. Only
the timer text is shown (along with tooltip) when content editing
is allowed.
Currently when a user does not have the permission to edit the topic/content
of a message, the edit UI/view source UI correctly shows a greyed
out topic/message-content input field, however these fields incorrectly have a
click behavior, so to fix this we now would want to use `disabled` prop instead
of `readonly` attribute as `readonly` controls can still function and are still
focusable whereas disabled controls can not receive focus and are unclickable.
Fixes#22565.
This was added by commit 7f174213ed, and
appears to have been designed for responses that are *successful* but
falsy. Logically, these should not implicitly represent a failure to
be retried if it were.
Note from tabbott: The background is that this idempotent retry loop
was a hacky workaround for a bug we never understood but saw daily in
production. Especially during server restarts / client reloads,
something would result in 200 responses with no data being seen by the
frontend, despite the Django server not having received/processed the
request. Fortunately, this strange failure mode appears to have
stopped happening in late 2019, so we can delete this hack.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Commit 9aa5082d63 (#20673) incorrectly
changed the name of the error callback passed to channel.get. This
prevented reporting of errors while moving a topic. Fix it.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
We ensure that if message edit is disabled, then we don't send
content in request to the server.
Refactored by tabbott to match the existing pattern for how we do this
for topic/stream edits.
This commit changes the code to consider zero as an invalid value for
message_content_edit_time_limit_seconds. Now to represent the setting that
user can edit the message anytime, the setting value will be "None" in
database and "unlimited" will be passed to API from clients.
Currently, if we navigate to some other topic/stream
while the message is being moved, the message edit UI
still remains open as we do not get its `row` in
`message_lists.current` since the message has not moved yet
to the stream/topic we navigated.
Hence the correct thing to do would be to delete
the message_id from `currently_editing_messages` if it
exists there but we cannot find the row.
Fixes#21724.
* Remove likely useless use of `controls` Bootstrap class.
* Remove outer control-group elements, which just added 10px bottom margin, and
were always used with .no-margin, which removed that margin :).
* Rename message-edit-timer-control-group to message-edit-timer, since
it isn't a control-group.
This immediately shows the menu for which messages to move when the
user can edit the stream/topic of a message, but not the content of
the message. This balances the concern that this menu might feel like
clutter when doing a content edit with the fact that most of the time
when one visits this menu without content edit permissions, one will
want to be reassured that one can choose which messages to move.
Fixes#19196.
After some discussion with the community, we've concluded that in most
cases, one probably wants to notify only the destination thread, not
the source location; so let's make that the default.
We preserve the model that we remember what you did during the last
move in a given browser session, which is very helpful if you're doing
an operation N times in a row.
Fixes#21838.
Creates a helper function in `message_edit.js` that loops over
a message's edit history to see if a stream and topic pair
existed at some point in the message history.
Exports `util.lower_same` function to use for comparing
edit history topics as lowercase.
Also adds test for new function in `mesage_edit` node tests.
We have two different frontend implementations of computing the
un-resolved form of a topic name, and they have a subtle -- but
intentional -- difference in behavior.
Factor them both out into the resolve_topic module, along with
their inverse, and with comments and tests.
Since we have the drafts button in top left corner and we need space
to insert formatting buttons in the bottom of compose box; removing
drafts link makes sense.
We attach the DOM for the modal to the body element
to avoid style interference from other elements and having to choose
a separate parent element for every single dialog_widget.
This fixes an issue where the auto-complete dropdown doesn't reflect
the changed stream in the message edit UI.
We add an unlisten method to the typeahead library to support this
reinitialization cleanly and in a way that can be readily reused in
the future.
Fixes#19874.
This commit replaces 'allow_message_deleting' boolean setting
with an integer setting 'delete_own_message_policy'. We have a
separate dropdown now for deciding which user-roles can delete
messages sent by themselves and the time-limit setting droddown
is different.
This new setting has two options - everyone and admins only. Other
options including moderators will be added further.
We also remove the "Never" option from the original time-limit
dropdown, as admins are always allowed to delete message. This
never option resembled the case of only admins being allowed to
delete but this state is now resembled by setting the dropdown
to "admins only" and we also disable the time-limit dropdown in
this case as admins are allowed to delete irrespective of limit.
Note, this setting is only for deleting messages sent by the
deleting user themselves, and only admins are allowed to delete
messages sent by others as before.
We make zero invalid value for message_content_delete_limit_seconds and
for handling the case of "Allow to delete message any time", the API-level
value of message_content_delete_limit_seconds is "anytime" and "None"
as the DB-level value. We also use these values for message retention
setting, so it helps maintain consistency.
There is a bug when multiple message edit forms are opened at the
same time where undefined value of stream_id is sent to the server.
This happens because a global variable stream_widget is used to get
the id of stream selected in dropdown and value of stream_widget
variable keeps on changing when we open multiple message edit forms.
Thus, stream_widget can have the dropdown widget of already closed
edit form resulting in undefined value of stream id.
This commit changes the save_message_row_edit function to access
the dropdown element directly using message id instead of using
stream_widget.value() and thus we always use the correct dropdown
element to get the stream id.
We also move the stream_widget variable to be inside edit_message
function instead of being global variable for the module.
Fixes#19663.
Rohitt Vashishtha
Mateusz Mandera
Sahil Batra
Julia Bichler
Akarsh Jain
Tim Abbott
jai2201
Anders Kaseorg
Aman Agrawal
Ganesh Pawar
Lauryn Menard
Greg Price
Priyam Seth
Pradyumna Sinha
sahil839