`disable-message-edit-history`: Remove text about EDITED label
and link to `view-a-messages-edit-history` instead.
`edit-or-delete-a-message`: Reformat 'EDITED' and '(deleted)'
to be bold instead of using backticks. Make link to view
edit history clearer.
Note that the text used in the `OpenGraphTest` in
`test_middleware.py` had to be updated for the changes to
`disable-message-edit-history`.
This is especially to add more space around the globe icon since
it wider than lock icon, so the previously set padding for the
stream icon has to be increased.
Adds a note about auto-notification messages that are sent when
these general settings are changed for a stream: name, description,
access and posting permissions, and message retention.
This lets Black support a Python 3.7 async comprehension syntax, but
has no effect on our current code.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This avoids an error when a user has already muted the new topic name.
We do this by ignoring duplicates, rather than catching the
IntegrityError, because this edit happens in a transaction, and that
would abort the transaction.
We had skipped these in #14693 so we could keep generating a friendly
error on Python 3.5, but we gave that up in #19801.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
This is necessary for the migration 0386_fix_attachment_caches to run,
and likely makes more convenient any future parallel code interacting
with both Attachment and ArchivedAttachment.
Our original implementation of moving muted topic records when a topic
is moved took a shortcut of treating all change_later usage as
something with intent to move the whole topic.
This works OK when moving the whole topic via this interface, but not
when moving a last off-topic message in the topic.
Address this by changing the rule to match the existing
moved_all_visible_messages variable.
Updates `/for/` pages for the new translated language count, 23.
Also, updates any links to help center documentation that have
been changed.
Finally, updates `/for/events` text for a potentially confusing
English idiom.
We use `fadeOut` effect to hide the scroll to bottom button more
widely. We already use `fadeIn` effect to display the button
every time.
We deliberately don't use the `fadeOut` effect when doing
`make_compose_box_full_size` to avoid any button overlap with
compose for a short time.
The implementation closely follows `handle_deactivation()`.
Using the same existing reactivate confirmation modal.
Also, this commit will also lead to open confirmation modal
to reactivate bots in settings > bots, and currently there is no
existing confirmation modal for deactivating bots.
This commit is a follow-up of #21436.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
We previously added support for showing the status_emoji to the PM
list, but we only supported individual PMs and not group PMs, this is
prep commit towards supporting group PMs.
Updates the list of actions and buttons referenced in the help
center documentation for viewing images with lightbox.
Also, makes some minor corrections to the keyboard shortcut note.
Fixes#21527.
Adds tab for web-public streams in documentation for setting
who can create new streams, as well as some text about why
this is limited to certain roles.
Removes list of actions that can be restricted to full members
due to maintainability concerns for that type of list in the
documentation and replaces it with a short descriptive text
explaining that many settings in Zulip support this restriction.
Updates various articles related to editing messages (settings,
edit history, etc) for changes in UI, adding undocumented
settings, and cleaning/linking documentation text and headers.
This change was motivated by the addition of status emoji to the buddy
list. Previously there was no spacing between the status emoji and the
unread count, and as such, this commit adds a left margin to the
unread count.
The above change has an additional consequence, long user names such
as "Othello, the Moor of Venice" get truncated with ellipses, instead
of reaching to the edge of the unread counts (as they previously
would).
While the 2px value that we had previously chosen looked alright for
most emoji (😀, 😃, etc) some emoji such as 🐙
used more of the width available to them and as such still looked too
close to the user name. As such this commit bumps the value to 3px
(4px was a bit too much space).
- `user-groups`: Add warning for removing yourself.
- `restrict-wildcard-mentions`: Updated setting name to match UI.
- `format-your-message-with-markdown`: In-app help is now an icon.
- `web-public-streams`: Add link to Zulip's Rules of Use.
Previously, we were experiencing a regression in the positioning of
the play icon for youtube previews, as such, this commit uses a
previously created `handle_video_preview_mouseenter` to ensure the
positioning is always correct.
This is an ugly way of doing things, because this could be handled
directly through CSS flexbox, however, it is an acceptable temporary
fix.
This commit extracts the logic used to ensure that the play icon is
correctly positioned over the video preview for embedded videos, with
the intention that we can use this to fix a regression in the play
icon positioning for youtube video previews.
We render a login button for images that failed to load for
spectators. The image failed to load most likely due to being
rate limited by the server.
Fixes#19840
This migration needs to be run after the previous commit is deployed
to a given Zulip installation, to fix any stale values of
is_realm_public and is_web_public.
Previously, Attachment.is_realm_public and its cousin,
Attachment.is_web_public, were properties that began as False and
transitioned to True only when a message containing a link to the
attachment was sent to the appropriate class of stream, or such a link
was added as part of editing a message.
This pattern meant that neither field was updated in situations where
the access permissions for a message changed:
* Moving the message to a different stream.
* Changing the permissions for a stream containing links to the message.
This correctness issue has limited security impact, because uploaded
files are secured both by a random URL and by these access checks.
To fix this, we reformulate these fields as a cache, with code paths
that change the permissions affecting an attachment responsible for
setting these values to the `None` (uncached) state. We prefer setting
this `None` state over computing the correct permissions, because the
correct post-edit permissions are a function of all messages
containing the attachment, and we don't want to be responsible for
fetching all of those messages in the edit code paths.
When the credentials are provided by dint of being run on an EC2
instance with an assigned Role, we must be able to fetch the instance
metadata from IMDS -- which is precisely the type of internal-IP
request that Smokescreen denies.
While botocore supports a `proxies` argument to the `Config` object,
this is not actually respected when making the IMDS queries; only the
environment variables are read from. See
https://github.com/boto/botocore/issues/2644
As such, implement S3_SKIP_PROXY by monkey-patching the
`botocore.utils.should_bypass_proxies` function, to allow requests to
IMDS to be made without Smokescreen impeding them.
Fixes#20715.
f0c680e9c0 introduced a call to
message_helper.process_new_message without first calling
message_store.set_message_flags on the message.
This resulted in it being possible as a race, when loading the Zulip
app to a stream/topic/near narrow, for a message to have the
`historical` flag be undefined due to not being initialized.
That invalid state, in turn, resulted in the message_list_view code
path for rendering the message feed incorrectly displaying additional
recipient bars around the message.
We could fix this by just calling message_store.set_message_booleans
in this code path. However, this bug exposes the fact that it's very
fragile to expect every code path to call that function before
message_helper.process_new_message.
So we instead fix this by moving message_store.set_message_booleans
inside message_helper.process_new_message.
One call point of concern in this change is maybe_add_narrow_messages,
which could theoretically reintroduce the double set_message_flags
bugs detailed in 9729b1a4ad. However, I
believe that to not be possible, because that call should never
experience a cache miss.
The other existing code paths were already calling
set_message_booleans immediately before
message_helper.process_new_message. They are still changing here, in
that we now do a cache lookup before attempting to call
set_message_booleans. Because the message booleans do not affect the
cache lookup and the local message object is discarded in case of a
cache hit, this should have no functional impact.
Because I found the existing comment at that call site confusing and
almost proposed removing it as pointless, extend the block comment to
explicitly mention that the purpose is refreshing our object.
Fixes#21503.
This eliminates an annoying bundle of complexity that caused the
frontend markdown processor's interface with the rest of Zulip's new
message processing code paths being more similar to that of a new
message from the server.
It also cuts down on code duplication.
The previous message.unread block in insert_local_message was
non-functional. markdown.apply_markdown is overriding what that set by
calling message_store.init_booleans, which happens to set the same
value for the `unread` flag, and then setting individual message
booleans as it finds elements like mentions during rendering.
Improve this situation partially by deleting the message_unread block,
and adding conversion logic to translate what the markdown processor
is doing into message flags.
Then, we can call message_store.set_message_flags just like we do when
processing new messages arriving via the API. This will be helpful
shortly, when we deduplicate the calls to
message_store.set_message_flags.
As noted in the lengthy TODO, this exposes the fact that we should
really rework how the frontend markdown processor returns the
mentioned state to its caller.
Moves descriptions of notification and subsetting options
when moving content out of the instructions tab blocks
and into descriptive text.
Adds documentation for editing a topic via the message
recipient bar.
Also cleans up a few changes to UI interactions.
Co-authored-by: Alya Abbott <alya@zulip.com>
Lauryn Menard
Alex Vandiver
Alya Abbott
Aman Agrawal
Anders Kaseorg
yogesh sirsat
Tim Abbott
YashRE42