Currently, we're unable to convert messages from Slack's integration
bots because this message subtype doesn't come from a Slack "user", that
is they don't have a Slack user profile.
This is a preparatory change to support converting Slack's integration
bot messages. This commit artificially creates Slack user data from the
integration bot's "profile" so that we can create a corresponding Zulip
user for them.
Part of #31311.
This commit changes the code in such a way that the
"Start new conversation" button open the compose box with the channel
picker open, as we do when no channels is selected.
Fixes#28410.
Co-authored-by: Kunal Sharma <v.shm.kunal@gmail.com>
This commit updates the logic to disable the reply button based on the
user's permissions in the stream.
Fixes part of #28410.
Co-authored-by: Kunal Sharma <v.shm.kunal@gmail.com>
Renames should_schedule_upgrade_for_legacy_remote_server parameter
to upgrade_when_complimentary_access_plan_ends in both
process_initial_upgrade and compute_plan_parameters, as well as
associated variable names and relevant code comments.
Renames the remote_server_legacy_plan parameter in
process_initial_upgrade to instead be complimentary_access_plan,
as well as some relevant code comments in that function.
The "cancel-legacy-server-upgrade-button" class attribute was not
being used in CSS rules or frontend biling code, so these changes
remove it instead of renaming it.
This is a follow-up to #32693, which missed a bunch of places due to
varying ways of typing Azure AD. (Azure AD, Azure Active Directory etc.)
In the diff there's an apparent inconsistency with renaming, in some
places renaming to just "Microsoft Entra ID" and in others
"Microsoft Entra ID (AzureAD)".
The idea is to add (AzureAD) in ordinary documentation, as it can help
clarity since many people still think of this as AzureAD, while sticking
with brevity and cleanliness of just using the official name in
marketing focused material.
Change alignment of footer rows to flex-start a bit earlier.
`1280px` is chosen since that's the standard `max-width` for
the screens on the page and that is width around which the
massive gap before the first item on the footer is diminished which
allows us to left align the elements.
If the user has enabled the option to automatically offer to update
their profile time zone with the browser's time zone, we show an alert
offering that.
Clicking on "Yes" updates the timezone.
Clicking on "No, don't ask again" disables (unchecks) the option.
A feedback toast is displayed to indicate the success/failure of the
request.
The alert is also shown if the user has not set their time zone.
Fixes#16957.
We add a variable `browser_time_zone` to track the same
separately from `display_time_zone`.
This is used to check whether the user profile time zone matches
the browser's time zone, as a part of #16957, and will later be
used in #16958.
We also add methods to check whether a given timezone is the same
as that of the browser, making use of the browser's own
canonicalization process.
Tests are added to ensure that the time zone comparison
logic works for timezones observing DST.
Fixes part of #16957
Added a checkbox to toggle the option to automatically offer
to update the time zone with the browser time zone,
which is handled by the user profile field
"web_suggest_update_timezone".
A tooltip is also attached explaining the feature.
Fixes part of #16957
This field tracks whether the user should be shown an
alert offering to update their profile time zone to the
time zone of the browser in case they differ.
The field is added to RealmUserDefault and UserProfile
models with a default value of True.
Fixes part of #16957
Removes deprecated `user` object from reactions objects returned by
the API as it is redundant because of the presence of `user_id` field in
the API and is not used by any clients now.
Since the initial fetch has a lot of messages, it can add many topics
to the left sidebar which can move the selected topic out of the view.
Note that `has_scrolled` is triggered even for the scrolls not triggered
by user since it is not easy to differentiate between the two events.
So, it is okay to ignore it initially.
