We separate the message editing and message moving settings
into different sections.
We do not change the help-links for the section headings and keep
both of them same linked to "Configure message eiditng and deletion"
as we would anyway be changing or spliting this page and can update
the links at that time.
This commit renames "can_edit_topic_of_any_message" function
in models.py to "can_move_messages_to_another_topic" and
"user_can_edit_topic_of_any_message" function in settings_data.js
to "user_can_move_messages_to_another_topic".
This change is done since topic editing permission does not
depend on message sender now and messages are considered same
irrespective of whether the user who is editing the topic had sent
the message or not. This also makes the naming consistent with
what we use for the label of this setting in webapp and how we
describe this action in help documentation.
This commit updates the labels for "edit_topic_policy" and
"move_messages_between_streams_policy" settings.
The label for topic editing setting is changed to
"Who can move messages to another topic" since the topic
edit permissions do not depend on message sender now and
messages are considered same irrespective of whether the
message was sent by the user editing the topic or by
someone else.
The label for stream editing setting is changed to
"Who can move messages to another stream".
These changes also makes the labels consistent with how these
actions are described in help center documentation.
This commit changes the topic edit permssions in webapp to not depend
whether the user editing the message had sent the message or it was sent
by someone else. Backend changes were done already in previous commits.
Previously, we always allowed topic edits when the user themseleves had
sent the message not considering the edit_topic_policy and the 3-day time
limit. But now we consider all messages as same and editing is allowed only
according to edit_topic_policy setting and the time limit of 3 days in
addition for users who are not admins or moderators.
This commit changes the topic edit permssions to not depend whether the user
editing the message had sent the message or it was sent by someone else.
We only do backend changes in this commit and frontend changes will be done
in further commits.
Previously, we always allowed topic edits when the user themseleves had
sent the message not considering the edit_topic_policy and the 3-day time
limit. But now we consider all messages as same and editing is allowed only
according to edit_topic_policy setting and the time limit of 3 days in
addition for users who are not admins or moderators.
We now allow editing stream and topic of message even if
allow_message_editing if False using webapp given that is
allowed as per other topic and stream edit specific settings.
Fixes a part of #21739.
We change the topic and stream edit permssions to not depend on
allow_message_editing setting in the API and are allowed even
if allow_message_editing is set to False based on other settings
like edit_topic_policy and can_move_message_between_streams.
Fixes a part of #21739.
All instances of `choice` have been replaced with `option` in the UI
for editing a poll. In code, `option` was already being used. This
ensures the same terminology is used across the code, the UI and the
related help center article.
"is_pm_recipient" is not supposed to be called with an arbitrary
recipient object which might have "to_user_ids" being undefined.
Since this helper is only used with focused_recipient in
compose_fade_helper, we move it there.
Note that the helper is no longer separately tested. It is now covered
by the test case of "compose_fade_helper.would_receive_message".
(See
5e74a8d0cc/static/js/compose.js (L156-L162))
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This avoids "@typescript-eslint/restrict-template-expressions" when we
convert util.js to util.ts.
Note that prettier would otherwise split the first template literal
expression in half if we don't start a newline.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This uses the linkifier index among the list of linkifiers in the
replacement as the priority to order the replacement order for
patterns in the topic. This avoids having multiple overlapping matches
that each produce a link.
The linkifier with the lowest id will be prioritized when its pattern
overlaps with another. Linkifiers are prioritized over raw URLs.
Note that the same algorithm is used for local echoing and the
backend markdown processor.
Fixes#23715.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
This explicitly enforces ordering on the linkifiers. This is useful when
there are overlapping linkifier patterns that matches the same text. In
our current linkifier implementation, this order affects how the
patterns are handled in the markdown processor, with the earlier ones
being prioritized.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
The same pattern being matched multiple times in a topic cannot be
properly ordered using topic_name.find(match_text) and etc. when there
are multiple matches of the same pattern in the topic.
Signed-off-by: Zixuan James Li <p359101898@gmail.com>
transifex-client went EOL on November 30, 2022, replaced by
transifex/cli [^1].
Swap this in-place, since per the upstream README [^2]:
> The current version of the client maintains backwards compatibility
> for the tx push and tx pull commands. So, if you have a CI setup that
> uses them, you should not have to change anything.
As the mobile team found out, this is a partial truth if one previously
used some of the more advanced CLI flags, but all workflows referenced
in tools/ and docs/ use forwards-compatible flags to the new version.
[^1]: https://github.com/transifex/transifex-client/
[^2]: a0f28a1cf3/README.md
This commit adds required bootstrap CSS rules used for emails
textarea element in invite modal with existing CSS for that
element in zulip.css. We also change the selector to use class
instead of ID such that the dark theme CSS can take precedence
when using dark theme.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds required bootstrap CSS rules used for message-edit
textarea element with existing CSS for that element in zulip.css.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds required bootstrap CSS rules used for
compose textarea element in with existing CSS for that
element in compose.css.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds required bootstrap CSS rules used for textarea
element in sponsorship page with existing CSS for that element
in billing.css.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds required bootstrap CSS rules used for textarea
element in support page with existing CSS for that element in
portico_signin.css.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds bootstrap CSS rules used for textarea element
in devtools integrations panel in integerations_dev_panel.css.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
This commit adds margin-bottom property to CSS of email field
in user deactivation modal with other CSS properties for this
field in settings.css since we are going to remove bootstrap
CSS rules in further commits.
This commit extracts some common bootstrap rules used for textarea
elements in settings (both organization and stream settings) and
this rules are added for settings_textarea class. We also add
settings_textarea class to the textarea elements in settings.
This change is done so we can safely remove textarea CSS rules
for bootstrap.css as a part of our process to remove bootstrap
without changing existing design.
The `stream_id` property of a stream object was being wrongly accessed
as `id`, which does not exist, in the function
`get_available_streams_for_moving_messages()`
This led to the current stream not being rendered in the dropdown list
as expected in the `Move Topic` modal when the user does not have the
permission to post in the current stream.
We don't need to select the message after fetching messages if
the user changed the narrow in the meanwhile.
Note that in this context, message_lists.current ===
message_list.narrowed.
Sahil Batra
N-Shar-ma
Ujjawal Modi
Yuri Sulyma
Zixuan James Li
Josh Klar
Tim Abbott
Aman Agrawal
evykassirer
Riken Shah
Clara Gallon