The Slack API when returning the emoji records, returns the record for
its thumbsup_all emoji with the url ending with .png, even though the
file is a gif.
For that reason, we have to make that code correct file extensions based
on the response content-type. Emojis are the smallest set of images to
download, so for simplicity of implementation, we remove the
parallelization of the downloads in favor of just processing them
serially.
(cherry picked from commit 9cad9644e7)
Ideally this would besplit up into two commits, but it's hard to split
into self-contained, atomic chunks now that this segment of the
import/export system is generally kind of broken after thumbnailing
system changes.
1. 3rd party export converters don't make .original image files.
Insteadthey provide a single file, which the import should treat as if
it's .original.
2. 3rd party converters create all the records with is_animated=False.
That's an issue, because without setting that correctly on the
RealmEmoji objects, Zulip doesn't know that it should use the "still"
thumbnail when the emoji is being used in a user's status. Which leads
to incorrectly displaying the user status with the distracting
animation.
(cherry picked from commit 669e0a3e47)
The export tool was only exporting the already-thumbnailed emoji file,
omitting the original one. Now we make sure to export the .original file
too, like we do for avatars, and make the import tool process it
directly, to thumbnail it directly and generate a still in the case of
animated emojis.
Otherwise, the imported realm wouldn't have the <emoji>.png.original
file that we generally expect to have accessible, and stills for
animated emojis were completely missing.
(cherry picked from commit 5476340b52)
Since each loop may add more than one file to the `storage_paths`
list, this may result in more than 1000 files being sent to
delete_message_attachments. Since the S3 backend only supports 1000
elements being deleted at once, we must partition the list into chunks
which are no more than 1000 elements long.
(cherry picked from commit 704423787b)
This prevents, among other things, `libvips` from pulling in the
`firefox` package by way of the `nip2` package.
Fixes: #31411.
(cherry picked from commit e8f7e281a7)
This removes the `.message_embed > *` selector which was expensive, and
instead moves the styles to the specific elements that need them.
(cherry picked from commit 5549e807eb)
This was due to non message list views didn't know that they
shouldn't try to process hotkey when DM search input is in focus.
(cherry picked from commit 1ce9fcdada)
Previously, comment related notifications only displayed the issue
title as a plain string. This commit reformats the issue title to
include a link back to the Jira issue.
(cherry picked from commit 68c87dbdf8)
Adjusted the Jira documentation for recent changes in their UI
when setting up webhooks, reformatted the note about compatible
Jira version, and added a link to Jira's official webhook guide.
(cherry picked from commit c952e7ae86)
This bug was introduced in da9e4e6e54.
validate validate_plan_for_authentication_methods is already called
inside validate_authentication_methods_dict_from_api, conditionally on
settings.BILLING_ENABLED. This additional, redundant call runs
regardless of BILLING_ENABLED, and thus prevents a self-hosted server
from enabling certain backends in the organization settings UI.
The impact of this is limited - in order to encounter this bug, a
self-hosted server would have to first disable the backend in the UI, as
self-hosted realms are created with all backend flags enabled. A backend
doesn't show up in the org settings UI until it is first enabled in
AUTHENTICATION_BACKENDS in settings.py - that's why this is a rare
state. A sequence of steps like this has to be followed to reproduce:
1. Add the backend to AUTHENTICATION_BACKENDS in settings.py.
2. Disable the backend in the org settings UI.
3. Now try to re-enable it, which fails due to the bug.
(cherry picked from commit 114f13e0ee)
A utility command to enable or disable certain authentication backends
for a realm from the command line. Can be helpful e.g. if the
administrator accidentally disables some auth methods in the UI leaving
themselves with none remaining that they could actually use to log back
into the organization.
Example usage:
```
(zulip-py3-venv) vagrant@c32c137f59a0:/srv/zulip$ ./manage.py change_auth_backends -r zulip --show
Current authentication backends for the realm:
Enabled backends:
Dev
Email
GitHub
GitLab
Google
Apple
SAML
OpenID Connect
(zulip-py3-venv) vagrant@c32c137f59a0:/srv/zulip$ ./manage.py change_auth_backends -r zulip --disable GitHub
Disabling GitHub backend for realm Zulip Dev
Updated authentication backends for the realm:
Enabled backends:
Dev
Email
GitLab
Google
Apple
SAML
OpenID Connect
Disabled backends:
GitHub
Done!
(zulip-py3-venv) vagrant@c32c137f59a0:/srv/zulip$ ./manage.py change_auth_backends -r zulip --enable GitHub
Enabling GitHub backend for realm Zulip Dev
Updated authentication backends for the realm:
Enabled backends:
Dev
Email
GitHub
GitLab
Google
Apple
SAML
OpenID Connect
Done!
```
(cherry picked from commit bf7fc5701f)
Earlier, we were replacing too long attachment name with random uuid
when the character count of the file name was greater than 255.
This results in "OSError: [Errno 36] File name too long" error in
few cases when the file name has less than 255 characters but more
than 255 bytes (file name with Non-ASCII characters).
This commit updates the code to check the file name's byte size
instead of characters count.
(cherry picked from commit 19d56f77b5)
This commit adds a note to NOT shut down Rocket.Chat server
while creating database dump using mongodump utility because
as this results in bugs like empty instances.bson file and
empty uploaded data after import.
(cherry picked from commit 54492ec7a0)
We ignore Rocket.Chat livechat channels/messages. It was
implemented in #20195.
This commit documents the caveat.
(cherry picked from commit adae69c65f)
Have one inbox row and focus on it. Mark the message as read in
another tab. Press `r` in the first tab will return an error as
the row_focus didn't change but there is no present. So, we
fix it by updating the row_focus if it can get out of bounds
when updating inbox view.
(cherry picked from commit 2011e0df76)
Scroll to bottom button is visible for a few ms when switching
narrow to Inbox / Recent view while scrolling in message feed.
While we can end the transition faster to completely avoid the issue
for now but this seems like a more permanent and simpler fix
than to fiddle with CSS.
(cherry picked from commit a43c0693b7)
The default compression level is 1; increasing this to 3 takes a small
amount more CPU time (single-digit ms on multi-MB transfers), but
results in a small but noticeable (4-7%) percentage better
compression in JSON content.
Assuming a 25 megabit connection (the current average data rate for
cell phones in the U.S.), a 2MB file which is shrunk an additional 4%
saves approximately 25 milliseconds of transfer time; thus the
additional few milliseconds of CPU-time is well worth the cost. For
faster connections (e.g. 100 megabit), the tradeoff is more or less a
wash.
(cherry picked from commit 163863c0d1)
Without this, Django builds queries with which compare tables' "id"
fields to `("confirmation_confirmation"."object_id")::bigint`; the
explicit cast prevents the index added in the previous commit from
being used.
(cherry picked from commit 9e02e562bb)
This migration references the "confirmation" app for the first time,
which means we must have migrated at least part of it by this point.
Set the migration to depend on the latest "confirmation" migration at
the time of this migration.
(cherry picked from commit 2bc118892a)
Messages are rendered outside of a transaction, for performance
reasons, and then sent inside of one. This opens thumbnailing up to a
race where the thumbnails have not yet been written when the message
is rendered, but the message has not been sent when thumbnailing
completes, causing `rewrite_thumbnailed_images` to be a no-op and the
message being left with a spinner which never resolves.
Explicitly lock and use he ImageAttachment data inside the
message-sending transaction, to rewrite the message content with the
latest information about the existing thumbnails.
Despite the thumbnailing worker taking a lock on Message rows to
update them, this does not lead to deadlocks -- the INSERT of the
Message rows happens in a transaction, ensuring that either the
message rending blocks the thumbnailing until the Message row is
created, or that the `rewrite_thumbnailed_images` and Message INSERT
waits until thumbnailing is complete (and updated no Message rows).
(cherry picked from commit 6f20c15ae9)
Fixes#31188, removing a lot of useless high-entropy data from the
/register response.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
(cherry picked from commit 8f1a97f168)
evykassirer
Mateusz Mandera
Alya Abbott
Alex Vandiver
Karl Stolley
Sayam Samal
adnan-td
Aman Agrawal
PieterCK
Tim Abbott
Prakhar Pratyush
Prakhar Pratyush
Lauryn Menard
Anders Kaseorg