Updates delete_fixed_price_plan to use the same structure as
configure_fixed_price_plan. If there is a customer plan and it's
billable, then we delete the configured CustomerPlan object. If
there is no customer plan or it's a complimentary access plan, we
delete the configured CustomerPlanOffer object.
Instead of showing the "None" empty message, just hide the whole section
instead. Notably this uses the total user counts and not the number of users
rendered, so it's possible we'll still show the sections when they're partially
loaded or if they have inactive users (in which case we'd show the "view more"
links).
The exception is the "THIS CHANNEL" section which we always want to show,
since it can be confusing to see other sections without this section
present. More conversation on that here:
https://chat.zulip.org/#narrow/channel/101-design/topic/right.20sidebar.20design.20tweaks/near/2099241
- Restructure the introductory content to be more focused on the
overview.
- The bottom content was a stale duplicate of the bottom of the
installer page, dating from when this was a required step after
running the installer.
- Most of the longer-form sections were duplicates of sections of
either the installer page or the introductions of dedicated pages on
the topic. Remove these in favor of new entries in the popular
settings area.
- Mention storage as a popular setting to configure.
- Remove deleted Twitter integration from popular settings list.
We don't yet have the documentation that would allow organization
administrators to make decisions about what value to use for this
experimental setting.
This is more consistent with how other URLs work in Zulip.
Replaces `/message_edit_typing` with `/messages/{message_id}/typing`.
The `message_id` parameter, previously passed in the request body,
is now included in the URL path.
Although, currently there are no scenarios where we are using
bulk_access_messages for edit. But we might do so in the future, and
it's better to have an explicit argument called is_modiying_message in
that case, so that the person making that change makes a conscious
decision of setting that property.
This is valuable so that one is forced to explicitly make a decision
on what is correct when adding new callers. Past experience tells us that
not having to explicitly show the decision leads to people introducing
security bugs in PRs that the maintainer has to catch in review, and our
goal for access control code should be that security bugs are hard to write.
Fixes#33688.
We did not add any checks for `message_edit_typing` since it is not
possible to get to that state in the UI for an archived channel's
messages.
Fixes part of #33688.
This is valuable so that one is forced to explicitly make a decision
on what is correct when adding new callers. Past experience tells us that
not having to explicitly show the decision leads to people introducing
security bugs in PRs that the maintainer has to catch in review, and our
goal for access control code should be that security bugs are hard to write.
Fixes part of #33688.
This is a follow-up commit to d1de4457dc,
which had set the font-size for the alert popups to --base-font-size-px.
This removes that line of code, as it was pointed out by Tim Abbott
that the web/styles/alerts.css file was also being shared with portico
through the web/src/bundles/common.ts bundle, but the
--base-font-size-px variable doesn't exist there.
Removing the font-size property from the alert box doesn't affect its
styling since it still inherits the `--base-font-size-px` from the body
in the Zulip Web App.
Tests were failing due to credit usage being capture in the next
month instead of current if the current time is last day of the
month. To fix this, we mock current time to not be the last day
of any month.
The clipboard.write API requires new permissions and can throw
NotAllowedError under certain circumstances in the browser (and always
in the current version of Zulip Desktop).
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Earlier when a new user sent a message in empty string topic,
it resulted in an error while displaying the automatic new
visibility policy banner.
'topic_name' was missing.
This commit fixes the bug.
We do not fetch all the realm group settings using
select_related for register data now since it takes a
lot of time in planning phase. This commit updates
the code to fetch all the members and subgroups data
in user_groups_in_realm_serialized so that we do not
need to access each setting group individually.
user_groups_in_realm_serialized is updated to send the
required data accordingly.
Fixes#33656.
Following improvments are done in user_groups_in_realm_serialized-
- Members and subgroups are fetched using a single query using
union.
- Query to fetch groups now does not fetch setting fields since
we already have the members and subgroups of all the setting
groups and we can check if setting group was a named group
or not directly without checking named_user_group field of
UserGroup object as we have IDs of all named groups of the realm.
When a channel has both "general chat" and "" topic and a user
has visibility policy configured for both the topics, then
the migration to rename "general chat" to "" resulted in error
as it violated '(user_profile_id, stream_id, lower(topic_name)'
unique constraint.
This commit fixes the error.
For each row with topic="general chat", we create a new row
with topic="". On conflict we update the visibility policy
of the existing row -- we prefer the visibility policy of
'general chat' topic over "" as we're renaming 'general chat'
to "" so the configured policy of 'general chat' should be
preferred and any "" topic created wouldn't be intentional
or would be for testing purpose as it is not announced yet.
Finally, we delete the rows with "general chat" topic.
