The `.url` and `.source` fields were being inconsistently used. This
also makes `.source` field consistently into a URL when it is
generated, instead of being re-interpreted in `display_video` for some
formats.
If the content-type of the image is not in INLINE_MIME_TYPES, then we
do not expect browsers to be able to display it. This behaviour is
particularly confusing because the thumbnail will render properly,
since that will be in the more widely-supported WebP format, but the
lightbox will show a broken image.
In these cases, generate a high-resolution (4032x3024) "thumbnail"
which clients can choose to use instead. This thumbnail format is not
in the listed in the server's advertised thumbnail size list, because
it is not reliably generated for every image.
The transcoded thumbnail format is set on the `img` tag if it is
generated, and the original content-type is always passed to the
client, so it can decide how or if to render the original image. This
content-type is as the _original uploader_ specified it, so may be
incorrect.
The transcoded image is not animated, even if the original was. HEIC
files can nominally be animated, but in testing libvips was not able
to correctly recognize them as such. TIFF files are parsed as being
"animated," with one page per frame; this is of dubious utility, so
we merely transcode the first page. Always generating a static
transcoded image serves to also limit the computational time spent.
THUMBNAIL_OUTPUT_FORMATS is switched to be a tuple to ensure that it
is not accidentally mutated.
This commit updates the code to show the display name for system groups
instead of their original names which contain "role:" prefix in
membership status text.
This commit updates the code to show the display name for system
groups instead of their original names which contain "role:"
prefix in the members list shown in group edit and creation UI.
Fixes#31926.
The tus-js-client fingerprinting feature stores metadata on
previously uploaded files by default in browser local storage.
Since these local storage entries are never garbage-collected,
they can be accessed via the browser console even after
logging out, and contain some metadata about previously
uploaded files, which seems like a security risk for
using Zulip on a public computer.
We use our own implementation of url storage that saves urls
in memory instead. We won't be able to retain this history
across reloads unlike local storage, which is a tradeoff we
are willing to make.
This commit adds a `sender_id` parameter to the
`GET /streams/{stream_id}/email_address` endpoint to specify the
ID of a user or bot which should appear as the sender when messages
are sent to a channel using the channel email address.
Earlier, Email gateway bot was always the sender.
Fixes part of #31566.
This commit extracts the logic for creating or retrieving a channel
email token into a dedicated `get_channel_email_token` function.
This improves code clarity by decoupling token generation from
the email encoding process.
In Slack webhook integration setup, the only scenario where a message
payload contains a channel mention without the channels name is when the
user mentions a private channel.
e.g <#C07AVLQ3AUQ|>
This commit updates the string we use for such mention to "private Slack
channel" for better clarity.
Previously, the notification message only informed users that the
integration URL was registered with Slack's Event API. However, it might
be misleading to send an "integration is successful" message when this
happens because we didn't verify that the token has the required scopes
or if the Slack token is even added to the URL at all.
Now that the integration also verifies the `slack_app_token`'s scope,
it's now more appropriate to send a notification message like
`get_setup_webhook_message` to let the user know that the setup is
indeed successful.
- Replaces the magnifying glass icon with a new design that
aligns better with the purpose of finding channels.
- Matches the "Browse Channels" link styling with the link at
the bottom of the left sidebar for consistency
Fixes: #32914
Co-Authored-By: Vlad Korobov <terpimost@gmail.com>
Added colors to notify users when the message length is near
the limit or has exceeded it. Used distinct colors for each
case to provide clear feedback.
Fixes: #32171.
This commit ensures that if the color picker popover is opened via the
stream actions popover, we hide the stream actions popover and instead
show the color picker popover in its place, anchoring to the same
reference element.
This avoids the cluttering of the view with multiple layers of UI,
given that it is also possible to open the browser native color picker
from the color picker popover.
As a follow-up to the previous commit which replaces the spectrum color
picker instances with the custom color picker popover, this commit
removes the spectrum-colorpicker library and its related code from the
codebase.
This commit replaces the spectrum color picker used in the stream
popover and stream settings with a custom color picker popover, which
contains a grid of predefined color swatches and a custom color option.
The custom color option uses the HTML5 <input type="color"> which shows
the native browser color picker UI.
Fixes#14961.
This adds support for empty topic name for
'/messages/matches_narrow' endpoint.
Makes sure that using this endpoint in old clients
with topic name having the value of `realm_empty_topic_display_name`
field in `narrow` parameter works as expected.
This adds support for empty topic name for
'/messages/flags/narrow' endpoint.
Makes sure that using this endpoint in old clients
with topic name having the value of `realm_empty_topic_display_name`
field in `narrow` parameter works as expected.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds backward compatibility for topic names in `user_topics`
objects returned in `/register` response.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds backward compatibility for topic names in `unread_msgs`
objects returned in `/register` response.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, mark unread operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `update_message_flags` event type
when removing `read` flag
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to
`GET /messages/{message_id}/history` endpoint to decide whether
the topic names in the fetched messages can be empty strings.
If False, the topic names in the fetched response will have the
value of `realm_empty_topic_display_name` field in `POST /register`
response replacing "" for channel messages.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, typing operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `typing` event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, toggling topic visibility policy operation supports
empty topic name.
Adds backward compatibility for:
- `topic_name` field in the `user_topic` event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Now, message edit operation supports empty topic name.
Adds backward compatibility for:
- `topic` field in the `delete_message` event type
- `orig_subject` and `subject` fields in the `update_message`
event type
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds `allow_empty_topic_name` boolean parameter to `GET /messages`
and `GET /messages/{message_id}` endpoints to decide whether the
topic names in the fetched messages can be empty strings.
If False, the topic names in the fetched message will have the
value of `realm_empty_topic_display_name` field in `POST /register`
response replacing "" for channel messages.
This commit is a part of the work to support empty string
as a topic name.
Previously, empty string was not a valid topic name.
Adds a `empty_topic_name` client capability to allow client
to specify whether it supports empty string as a topic name.
Adds backward compatibility for:
- `subject` field in the `message` event type
This commit adds a `realm_empty_topic_display_name` constant,
which is returned in `POST /register` response if `realm` is
present in `fetch_event_types`.
Clients will use this value as the name of the topic where
messages sent without specifying a topic will appear.
This temporary change allows us to preserve these old styles
while iteratively move all the close buttons to new styles.
Once the migration is complete, `old_clear_search_button` won't
exist anymore and there will be new styles for `clear_search_button`.
Earlier, when a topic was deleted then UserTopic rows corresponding
to that topic were not deleted resulting in a bug where the topic
is listed in the '/#settings/topics' panel even after deletion.
This commit fixes the incorrect behavior to delete the concerned
UserTopic rows.
We need to take special care of the case when a topic is deleted
in private channel with protected history. We delete the UserTopic
records for exactly the users for whom after the topic deletion
action, they no longer have access to any messages in the topic.
This is a bit of an emergency fix to fix the build, but
it is probably close to what we want.
Any test that cares about the height of the compose box
can probably override this behavior. Likewise for any
css calls.
Previously, inserting a bulleted or numbered list via the compose
box added an extra blank line before and after the list.
This commit removes the extra blank line inserted before the list.
Fixes#32607.
This commit includes the following changes:
- The email field is now a disabled text field.
- An "Edit" (pencil) button is added next to the email
field, which opens the change email modal.
- The "Edit" button is not shown if the user doesn't
have permission to edit their email.
- When email changes are disabled, the "email changes are
disabled" tooltip now appears over the email field, which
previously appeared to the right of the email field.
- Refactor `settings_org.test.cjs` to align with the changes
of the added "Edit" button.
Fixes#31975.
This commit includes the following changes:
- The confirmation notice for email changes is moved from the
section heading to just below the email field.
- The confirmation notice is now shown as plain text instead
of a banner.
- Instead of `settings_ui.do_settings_change()`, `channel.patch()`
is used in the `do_change_email()` function to achieve the
aforementioned changes.
Fixes part of #31975.
