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.
This commit updates the GitHub webhook integration to include the
old issue number in the transfer message sent for the new repository,
alongside the old repository's full name.
We no longer archive private streams when they become vacant,
since user can still have permissions to subscribe to it.
And streams can anyways be archived manually if needed.
Fixes#33689.
Earlier, for topic-edit involving empty string topic the rendered
topic name was not buggy.
We used to display `""` instead of `realm_empty_topic_display_name`
with proper styling.
This commit fixes the bug.
This commit disables the save button when the topic name is considered
as empty as part of the `realm_mandatory_topics` being set to True.
Since disabled elements do not fire events, it is not possible to
trigger tippy tooltips on disabled elements – such as the Save button
in the inline topic edit UI. Thus this commit adds a tooltip to the
disabled save button by wrapping/unwrapping it inside a `span` wrapper
pragmatically via the `ui_util.disable_element_and_add_tooltip` and
`ui_util.enable_element_and_remove_tooltip` helper methods.
This commit adds the `invalid-input` class to the inline topic edit
input element when the new topic name is considered empty as a result
of realm_mandatory_topics property being set to True. This adds the
red glow borders to the invalid input field, which visually
communicates that some thing is wrong with the new topic name.
Previously, anytime Enter was pressed anywhere inside the inline topic
edit UI, it led to the submission of the form. This logic resulted in
the unintentional saving of the new topic name when Enter was pressed
even on the cancel button; which should have actually closed the inline
topic edit UI instead.
This commit makes sure to only save the new topic name when the user
presses enter when focused on the text input element or the save button.
