This mirrors the restrictions in
zerver.lib.message.bulk_access_stream_messages_query, in order to
prevent leftover UserMessage rows from granting access to messages the
user was previously allowed to access but no longer is.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
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 updates populate_db to mark all onboarding steps as seen
for existing users to avoid unnecessary popups during development.
Developers should create a new user in development environment
to test the onboarding steps.
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
We now return the members and subgroups ID list sorted for
settings that are set to anonymous groups. This is needed to
make sure we do not show save discard buttons when only pill
order is changed.
This commit fixes the code to not include deactivated groups in
stream setting values when the setting is set to an anonymous
group. This is consistent with what we do for realm and user
group settings.
As a result, we also deduplicate some code by using existing
function used for realm and group settings.
Add the `is:muted` search operator.
`-is:muted` is an alias for the `in:home` operator.
Co-authored-by: Kenneth <Kenneth012004@outlook.com>
Fixes#16943
This will allow clients to display MOVED/EDITED indicators, and their
tooltips, without interacting with the `edit_history` section of
message objects, which we plan to remove in the future.
Supporting that requires both introducing both last_moved_timestamp,
and changing the definition of last_edit_timestamp to not include
message moves, which involves recalculating it at the API layer.
The last_moved_timestamp is not present if the topic moves for the
message are for resolving or unresolving the topic. It is always
present for channel moves.
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Documents organization setting that configures what message edit
history can be viewed: content edits and topic/channel moves, only
topic/channel moves, or disabling viewing edit history completely.
Renames article to match new help article header and creates URL
redirect for previous article header.
Also, clean up and consolidate related articles.
Fixes#33684.
Co-authored-by: Alya Abbott <alya@zulip.com>
Use "restrict-wildcard-mentions" for open graph test of admonition
and link in the help article main description, instead of
"disable-message-edit-history" since that help article will be
revised to use a shared intro include file.
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.
This table's export and import weren't working:
1. It didn't have a Config in export.py, so it wasn't exported at all.
2. Its `date_created` wasn't registered in `DATE_FIELDS`.
3. It wasn't registered in `ID_MAPS` in import_realm.py, so having any
SavedSnippets in the export would cause the import to fail with an
exception.
4. It was missing a `fix_datetime_fields` call in its import codepath.
Without this change, the child tables of UserProfile didn't get their
objects exported if those objects were tied to a mirror dummy user.
For example, a `Recipient` of type `PERSONAL`, or the associated
`Subscription` would not get exported. Same for other tables with
foreign keys to `UserProfile` - such as `UserPresence`.
This happened because the Configs for the export are defined as follows:
```python
user_profile_config = Config(
custom_tables=[
"zerver_userprofile",
"zerver_userprofile_mirrordummy",
],
# set table for children who treat us as normal parent
table="zerver_userprofile",
virtual_parent=realm_config,
custom_fetch=custom_fetch_user_profile,
)
user_subscription_config = Config(
table="_user_subscription",
model=Subscription,
normal_parent=user_profile_config,
filter_args={"recipient__type": Recipient.PERSONAL},
include_rows="user_profile_id__in",
)
Config(
table="_user_recipient",
model=Recipient,
virtual_parent=user_subscription_config,
id_source=("_user_subscription", "recipient"),
)
```
while in `export_from_config` we have:
```python
elif config.normal_parent:
# In this mode, our current model is figuratively Article,
# and normal_parent is figuratively Blog, and
# now we just need to get all the articles
# contained by the blogs.
model = config.model
assert parent is not None
assert parent.table is not None
assert config.include_rows is not None
parent_ids = {r["id"] for r in response[parent.table]}
```
This meant that when processing a table with
`normal_parent=user_profile_config`, the `parent_ids` above would only
have the ids of `UserProfile` objects under the `zerver_userprofile` key in
the exported data - completely missing those in
`zerver_userprofile_mirrordummy`.
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.
This code path had not been properly updated for the new ways of
having content access to a channel.
Also adjust the error messages for missing content access.
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.
- Made the branch-filtering checks uniform across all the integrations,
by adding a helper function to git.py, and re-using it.
- Instead of checking if the name of the branch that generated the
event is a substring of the "branches" parameter, we now check if
there's an exact match.
For example, if there are two branches named "main" and
"release/v1.0-main", and the user wants to track pushes to only the
"release/v1.0-main" branch, they wouldn't have been able to
previously, it will always track pushes to both branches. There was no
way to filter out the smaller named branch when there were overlaps.
Edited the git-append-branches.md macro to match the previous
git-branches-additional-feature.md macro, and moved it inside the
webhook-url-with-bot-email.md macro, as it's only ever used
immediately after that macro.
Updated the Git-related integrations that support branch filtering:
- Removed the branch-filtering configuration option, and its macro.
- Added a new macro that integrates the branch-filtering instruction
with the Generate-URL step.
The new macro `generate-webhook-url-with-branch-filtering` builds off of
the `generate-webhook-url-basic` macro, adding only the branch filtering
instruction. But, it does not re-use the macro, instead duplicates it,
to avoid the newline break that would be added otherwise.
This commit ensures the `message_edit_history_visibility_raw`
parameter is validated using the policy names defined in the
`MessageEditHistoryVisibilityPolicyEnum`, used in the
`update_realm()` function in the `zerver/views/realm.py` file.
Follow up of #32840.
