UserGroupMembersData is not serializable by orjson. We will be
introducing a TypedDict (which is serializable) in the next commit
called UserGroupMembersDict. This rename will help us distinguish
between the two.
This commit updates the code which computes the dict for
setting groups mapping named user groups to ID and anonymous
groups to UserGroupMembersDict. After the changes, the dict
contains only anonymous groups values and the setting values
for group IDs not present in dict will be computed based on
the fact that those are named user groups.
This is a preparatory refactor for optimizing computing group
setting values for register response by fetching all anonymous
groups membership data just once.
This commit adds a one-time modal to display navigation tour
video to new users.
Includes an `NAVIGATION_TOUR_VIDEO_URL` server-setting to specify
the video's URL. When set to None, the modal is not displayed.
Fixes#29304.
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
Email clients tend to sort emails by the "Date" header, which is not
when the email was received -- emails can be arbitrarily delayed
during relaying. Messages without a Date header (as all Zulip
messages previously) have one inserted by the first mailserver they
encounter. As there are now multiple email-sending queues, we would
like the view of the database, as presented by the emails that are
sent out, to be consistent based on the Date header, which may not be
the same as when the client gets the email in their inbox.
Insert a Date header of when the Zulip system inserted the data into
the local queue, as that encodes when the full information was pulled
from the database. This also opens the door to multiple workers
servicing the email_senders queue, to limit backlogging during large
notifications, without having to worry about inconsistent delivery
order between those two workers.
Messages which are sent synchronously via `send_email()` get a Date
header of when we attempt to send the message; this is, in practice,
no different from Django's default behaviour of doing so, but makes
the behaviour slightly more consistent.
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.
This was confusingly doing an assertion about the subscription being
active, not the channel. We could rename it to
require_active_subscription. But it was only passed with a non-default
value in b2cb443d24, and that call was
removed in 378062cc83.
Fixes#33719
If the user is not subscribed to the new stream but is a subsriber
of the old stream, we were not sending any update events to the user.
This results in unexpected behaviour related to the message.
Passing the user group object in case of named user group is fine for
`do_change_stream_group_based_setting`. But for anonymous groups, if the
code path calling that function is not creating a new anonymous user
group, it has to modify the user group by itself before calling that
function. In that case, if `old_setting_api_value` is not provided,
`old_user_group` is calculated false, since the group id has not changed
for the stream, but the group membership has changed.
old_setting_api_value will be the same as new_setting_api_value in such
a case.
It is better to accept the new setting value as either an int or
UserGroupMembersDict, so that `do_change_stream_group_based_setting` can
decide what to do with that argument.
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.
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.
Fixes#33567.
We have used the flag `is_modifying_message` since it's more generic
than an archived channel specific flag and helps us understand better
what is the condition where we do not want to allow archived channels.
We have not added tests for message edit since it has an existing test
for this.
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 keep around the old `include_all_active` parameter for backwards
compatibility.
Web frontend doesn't use this API and thus there were no changes needed
there.
When sending invites and password reminders, ensure that the email
address is not on the AWS SES suppression list. Addresses often
mistakenly end up on there and are never removed; automatically
removing them, if necessary, before we reach out to attempt a signup
reduces support overhead and perceived buggy behaviour.
Added `ignored_because_not_subscribed` field in the response of
`/messages/flags/narrow` endpoint.
Fixes a part of #23470.
Co-authored-by: Hemant Umre <hemantumre12@gmail.com>.
This commit updates code to optimize computing users who have
metadata access via permission groups so that we do not have
to do DB query for each stream to get recursive members for
the groups having permissions.
This commit adds typing indicators for message editing in stream
as well as in dm, if the send typing notification
for corresponding is enabled.
Based on earlier work in #28585.
Co-authored-by: Rohan Gudimetla <rohan.gudimetla07@gmail.com>
Fixes#25719.
The comment was incorrectly placed and misleadingly suggested that
`long_term_idle` subscribers were excluded from `subscription_query`,
whereas they were not.
Previously, when description for a channel -- either during its
creating or when we change its description contained a topic
permalink (through #-mention), then it was not rendered. This
is because of lack of authorization to access the channel.
This is fixed by passing the acting_user through the methods
which update or add the description, so that permissions
of the acting_user could be used to determine whether to
render the #-mention in stream description or not.
Previously when system bots used to `#-mention` a private
channel's topics in cases like moving messages of a private
channel, then the #-mentions were not rendered by the
markdown. This was because the system bots did not have
authorization to mention these channels.
This is fixed by passing down an `acting_user` parameter
in code paths involving sending these move message
notifications so that permission of acting_user to mention
the topic is verified for rendering the markdown, rather
than that of the system bot.
When a user gets access to a private channel, they get a stream creation
event. Channel admins and users in `can_add_subscribers_group` already
have metadata access to a private channel and therefore do not need to
be notified.
We were not able to use
get_user_ids_with_metadata_access_via_permission_groups in the function
in question due to a cyclic dependency to `lib/streams.py`.
Users in `can_administer_channel_group` and `can_add_subscribers_group`
have access to private channel metadata. They should be notified of
relevant events.
We've only made relevant changes to lib/streams.py in this commit to
make the changes small and reviewable.
Earlier, we were passing the whole subscription object to the function
in order to check if the user was subscribed or not. In the future
commits, we want to check that without fetching and passing the complete
subscription object and this commit will help us do that.
When a stream configured for any of these settings is deactivated,
the corresponding realm settings should be set to NULL:
* new_stream_announcements_stream
* signup_announcements_stream
* zulip_update_announcements_stream
* moderation_request_channel
Earlier, we were not updating those realm settings to NULL.
We had helper functions like 'get_new_stream_announcements_stream'
to return None if the configured stream was deactivated.
But it makes more sense to just set them to NULL in DB.
This commit also includes a migration to clear those fields
if the configured channels are deactivated.
This commit fixes a bug introduced in commit `37f2c5bc788`,
where a message in DM is not updated to "(deleted)" when
left empty after editing.
Fixes: #33305
Previously, channel archival event messages were unread in
archived channels, which makes the archived channel accessible
from the inbox view.
This commit fixes this issue by auto-marking the channel archival
event message as read.
Fixes: zulip#33258.
