Server can now send partial data to the client to help in
developement. We don't want this to be widely used right now,
hence no documentation changes have been made.
This will likely be a check on client capability later.
This is a preparatory refactor for migrating the internal structure of
Recipient objects for group DMs to use the DirectMessageGroup type,
not the legacy PERSONAL type. This step has the message-sending code
path check if a DirectMessageGroupe exists and prefer it if available.
It should have no effect in production other than doing a useless
database query for each outgoing DM, since we do not at present ever
create such DirectMessageGroup objects. (It will not add a marginal
database query once the migration is complete, just during this
transition).
This commit adds a new personal setting
`resolved_topic_notice_auto_read_policy` which controls how
resolved-topic notices are marked as read for a user.
Fixes#33599.
This adds a new API endpoint that enables users to report messages for
review by admins or moderators. Reports will be sent to the
`moderate_request_channel`, so it must be configured for this feature to
be enabled.
Fixes part of #20047.
Co-authored-by: Adam Sah <140002+asah@users.noreply.github.com>
This just records the time when the user created the
request to schedule a message or set a reminder.
This would be unused but is future-proofing against a world
where we decide to edit the strings or UI to show when you
asked for the thing.
This commit updates code to not prefetch can_access_all_users_group
and can_access_all_users_group__named_user_group fields using
select_related. We can just use get_realm_system_groups_name_dict
function to check if setting is set to "Everyone" group when
needed and can avoid unnecessarily fetching groups for every user
query.
This commit refactors user_has_permission_for_group_setting
to accept setting group ID instead of UserGroup object.
We only need ID in checking the permission and this helps in
further commit to avoid prefetching can_access_all_users_group
setting.
This commit removes a misleading comment regarding
'zerver_message_edit_history_id' index.
We added the index in 0679 to use in 0680 but later the 0680 migration
was reworked resulting in the index not being used in 0680.
We didn't drop the index as we expect it to be helpful for other
things.
The comment was misleading hence removed.
This commit updates code to not pre-fetch DM permission
group settings using select_related and instead just
fetch the required data from DB when checking permission.
This will increase one query but will help in pre-fetching
the settings for all users and for all type of messages.
Fixes part of #33677.
Indexes on topic ("subject") are polluted by the existence of DMs,
which all have empty topics, and as such skew the statistics greatly.
This is particularly important given the new use of the empty topic
for the "general chat" function -- left as-is, the database makes bad
query plans because it believes the topic is vastly more common than
it actually is.
We move the old indexes to a new name with `_all`, and
recreate (concurrently) the same indexes but with a condition on
is_channel_message. These new indexes are unused at current, until
the query-building logic adds limits on is_channel_message; see the
following commit.
This commit separates the "resolve topic" permissions from the
topic editing permissions, through the introduction of setting -
"can_resolve_topics_group" which user group whose members
can resolve topics.
Fixes#21811
Removed `is_billing_admin` user property as it is no longer used since
billing permissions are now determined by `can_manage_billing_group`
realm setting.
Since this does impact the ability to access the channel's content, it
makes sense to permit changing subscriptions, just like other
permissions settings on the archived channel.
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.
Zulip now supports empty string as a valid topic name.
For clients predating this feature, such messages appear
in "general chat" topic. Messages sent to "general chat" are
stored in the database as having a "" topic.
This commit adds a migration to rename the existing
"general chat" topic in the database to "".
Fixes parts of #32996.
This commit implements the backend of migrating the
`allow_edit_history` setting to
`message_edit_history_visibility_policy`.
This allows organizations, to have an intermediate setting to
view only the "Moves" history of the messages.
We still pass `realm_allow_edit_history` in `/register` response
though for older clients with its value being set depending on the
value of `realm_message_edit_history_visibility_policy`. We set
`realm_allow_edit_history` to `False` if the
`realm_message_edit_history_visibility_policy` is "None", and
`True` for "Moves only" or "All" message edit history.
Fixes part of #21398.
Co-authored-by: Shlok Patel <shlokcpatel2001@gmail.com>
Co-authored-by: Tim Abbott <tabbott@zulip.com>
We were not actually using anything but the IDs here, so it was a
bunch of wasted work to fetch these.
This essentially reverts f48e87cd3c. At
the time, something like that was required, because we needed to check
if the channel was deactivated before exposing it to the API, but more
recent reworking of the system to change the setting if the channel is
deactivated, rather than masking it in fetch_initial_state_data, means
we can do this cleanup.
Adds a second Zoom integration that uses the Zoom Server to Server
OAuth app process. Only one of the two Zoom integrations can be
configured on a Zulip server.
Adds a cache for the access token from the Zoom server so that it
can be used by the server to create meetings for the approximate
duration of the access token
In the web-app compose box, if the user's delivery email does not
match a user on the configured Zoom account for the server to server
integration, then a compose box error banner will be shown when the
error response is received after clicking/selecting the video or
audio call button.
Also updates the production documentation for the both types of Zoom
integration apps (Server to Server and General). The General app
process for Zoom now requires unlisted apps to go through their
review process, which we now have documented.
Fixes#33117.
These were likely mistakenly left off of 6098c2cebe, leading to
1847086044 likely not switching to `base_get_user_queryset` for this
function because the list differed.
These two endpoints make up ~85% of requests to Zulip servers; since
presence is also a performance-critical endpoint, having them share
the same cache increases how hot it stays in memcached, in addition to
making the presence endpoint faster.
This comes at the very slightly cost of one extra field. Checks
for the `is_bot` column are switched to the equivalent `bot_type`
check, since the columns are slightly duplicative, and we can get away
with only checking bot_type.
Tornado requests try hard to not make SQL queries -- and if they're
necessary, to minimize the number of them. Specifically, both session
objects and user objects are cached in memcached, and we expect that
both of them will have been filled there by Django before any requests
are made to Tornado.
In the event that memcached is flushed, or data is otherwise evicted,
we perform two database queries -- one for the session, and one for
the user. However, the *width* of the latter query has grown
significantly over time, as the Realm object grew more fields, and
recently with the addition of role groups, which require multiple
joins each. This leads to a query which is over 12k of text long, and
results in 319 columns. In the event of a memcached flush, this can
result in a *significant* amount of SQL traffic, as nearly every
active Tornado request will make that query.
We do not wish to narrow the default query for Django; we instead tag
the request in the REST wrapper, and use that to use a much narrower
user cache entry. That narrower cache entry is filled before the
queue is created in Django; we also use it to explicitly set the log
data, so the second "half" of the continued Tornado request does not
need to fetch any user data either when writing its log line.
Because they use different cache keys, this only affects the
session-based `/json/events` endpoint, which caches by user-id; the
`/api/v1/events` endpoint, which uses an API-key cache, keeps its wide
user object. The former is 50% of the total request volume, whereas
the latter is only 2%, so adding an additional cache for it is
unnecessary complexity.
