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.
This is a prep commit for adding the support of Multiselect
dropdown list widget by prototypal inheritance.
The following change actually revamps the dropdown list widget
into a constructor function, due to which the widget is now to
be initialized with the `new` keyword (which adds a property
to __proto__ object that links to the constructor function's
prototype object).
Example-
const foo = new DropdownListWidget({....});
Due to the above change, this commit also modifies the declaration
of dropdown_list_widget across all our instances.
91b83cf09f migrated delete_topic modal
to confirm_dialog. confirm_dialog closes the modal after clicking on
the Confirm button. So manually closing the modal is redundant.
This commits replaces the custom `send_notification` message_edit
checkboxes with our `settings_checkbox` partial.
The main intention is to also support the feature of selecting a
checkbox by clicking over its corresponding label as we have
in the case of the organization settings checkboxes.
Due to above change, this commit also removes the redundant
`break-row` HTML class along with it styles.
We use img tag for showing the loading spinner in message edit form
and dialog-widget submit button, instead of object tag because using
object tag gives the following error- "Refused to display
'https://chat.zulip.org/' in a frame because it set 'X-Frame-Options'
to 'deny'." in the browser console.
As mentioned by Anders in czo, this is probably because we’re loading
the SVG using an <object> tag as if it’s totally-not-an-IE3-ActiveX-
control.
We also need to add a new svg file similar to loader.svg with the
change that the retangles are filled with black color. This needs
to be done because we cannot get access to the svg document if we
use img tag and so we cannot change the color of rectangles using
jquery as we were doing before to show the spinner depending on
day/night mode. So, now we just set the src attribute of img tag
to the correct svg file depending on day/night mode.
Discussed in #issues > loading tail-spin.svg denied by X-Frame-Options.
Implemented dropdown_list_widget in message_edit UI
which enables the functionality to search for streams
while moving a particular message across streams.
This matches the UI we have in the "move topic" widget.
Fixes#18416.
We used html_submit_button to pass text to be present in the modal
submit button. There are only two possible options as of now -
"Confirm" and "Save changes" and the correct one can be determined
using is_confirm_modal parameter. So, we remove this paramter for
now and we can add it later if we have more type of modals using
this widget.
This commit adds a new dialog_widget.js file containing most
of the code of confirm_dialog.js with some minor changes and
changes confirm_dialog to be a wrapper around dialog_widget.js.
We pass 'is_confim_dialog' as true in dialog_widget for a
confirm_dialog modal. This commit also renames confirm_dialog.hbs
and confirm_dialog_heading.hbs to dialog_widget.js,
dialog_widget.hbs and dialog_widget_heading.hbs respectively.
This commit renames the variables, functions used in confirm_dialog.js
and classes and ids used in confirm_dialog.hbs.
This change is made so that we can easily migrate edit_fields_modal to
use this same code with some more changes.
We will change the file names and correspondingly import variables in
the next commit.
Sahil Batra
Julia Bichler
Akarsh Jain
Mateusz Mandera
Tim Abbott
jai2201
Anders Kaseorg
Aman Agrawal
Ganesh Pawar
Lauryn Menard
Greg Price
Priyam Seth
Pradyumna Sinha
sahil839
aryanshridhar
Aryan Shridhar