Since it's the initial migration, this can't have any useful effect.
I'm pretty sure the backstory is we did a manual squash of migrations
during the process of open-sourcing Zulip, and incorrectly didn't
remove this code.
It's not possible to directly upgrade from pre-5.3 versions to main,
since they do not have any supported OSes in common. Thus, this
dependency on the confirmation model, which risks creating a circular
dependency if we squash migrations, can be removed.
Adds some validation for changing the realm's max invites via the
support view so that it is not set below the default max for the
realm's plan type, and so that if it's currently set to the default
max it's not reset to that same value.
This commit adds '*' as a keyboard shortcut to navigate to the starred messages view and the shortcut is documented in various required locations accordingly.
Fixes#31397.
The 10.0-dev tag was created on the wrong commit, and force-pushing
it would break upgrade-zulip-from-git. Merge it into main so that
cache-zulip-git-version detects the right version.
Signed-off-by: Anders Kaseorg <andersk@mit.edu>
This commit adds a new `group_size` field to the `DirectMessageGroup`
model, and backfills its value to each of the existing direct message
groups.
Fixes part of #25713
It is better to have stream dropdown option value, which is the ID
of the stream, to be of "number" type.
This fixes the assertion error which occurred when someone tried to
subscribe the user to a stream from user profile modal.
Earlier, we were using 'send_event' in 'do_change_is_billing_admin'
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_update_outgoing_webhook_service' which can lead to a
situation, if any db operation is added after the 'send_event'
in future, where we enqueue events but the action function fails
at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_set_push_notifications_enabled_end_timestamp' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_set_realm_stream' which
can lead to a situation, if any db operation is added after the
'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in
'do_set_realm_authentication_methods' which can lead to a situation
where we enqueue events but there's an error at a later stage in
the codepath using this function.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in do_set_realm_user_default_setting
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_regenerate_api_key'
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
Earlier, we were using 'send_event' in 'do_change_full_name'
which can lead to a situation, if any db operation is added after
the 'send_event' in future, where we enqueue events but the action
function fails at a later stage.
Events should not be sent until we know we're not rolling back.
Fixes part of #30489.
This commit updates code to live update the groups UI if
realm or group level setting to manage groups is changed.
This commit also does some refactoring to better organize the
code in different functions.
And also, the code to hide/disable the UI if the user does not
have permission to manage the group in JS such that the same code
is used for live-updating as well.
This commit fixes the live update of subscribers list
on changing can_remove_subscribers_group setting.
Previously, whole members panel, including the pill container
to add subscriebrs, is re-rendered. But the click and input
handlers for the add subscribers UI is not added again after
re-rendering and thus they do not work.
This commit updates the code to just re-render the subscribers
list which is only needed to update the "Unsubscribe" button.
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.
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.
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.
As detailed in the comment in the code:
The upstream implementation uses the outdated /oauth2/authorize
API (instead of the v2.0 API), which doesn't allow us to authenticate
users with just a personal Microsoft account. v2.0 API is required.
This requires us to override the default URLs to use it as well
as adjust the requested scopes, to match this new API.
The backend in its previous state was only able to authenticate users
that were tied to an organizational directory, even if the application
settings in Azure were set up to also allow personal accounts. Users
trying to use a personal account would face an error from Microsoft:
AADSTS500200: User account 'xxxx@example.com' is a
personal Microsoft account. Personal Microsoft accounts are not
supported for this application unless explicitly invited to an
organization
https://github.com/python-social-auth/social-core/issues/723 is a
related upstream issue.
Tim Abbott
Alex Vandiver
Lauryn Menard
opmkumar
Aman Agrawal
Anders Kaseorg
afeefuddin
Varun Singh
roanster007
Alya Abbott
Sahil Batra
Shubham Padia
Prakhar Pratyush
Karl Stolley
Mateusz Mandera
evykassirer
Rahul Rajesh Kumar