For get and filter queries of NamedUserGroup, realm_for_sharding
field is used instead of realm field, as directly using
realm_for_sharding field on NamedUserGroup makes the query faster
than using realm present on the base UserGroup table.
Fixes#21544.
The network prefix (e.g. 64) identifies the network portion
which determines which bucket should that IPv6 belong to.
Implemented as a generic approach, so we have the option
to use different prefix sizes (leading to different buckets)
in the future.
Add comprehensive assertions for which IPv6s
are expected to belong to the same bucket and which are not.
The DjangoIntegration is explicitly disabled, because it attempts to
hook into the request handling in a way which is not compatible with
Tornado, and leaks event handlers.
`settings.ZULIP_SERVICES_URL` is used to construct curl
example for `/api/register-remote-push-device`.
On zulip cloud `settings.ZULIP_SERVICES_URL=None`, it resulted
in 500 error on visiting that page.
This commit fixes the bug by using "https://push.zulipchat.com"
as the default value if `settings.ZULIP_SERVICES_URL=None`.
The doc already mentions that the endpoint is meant to be used
by self-hosted servers, so the default value makes sense if
ZULIP_SERVICES_URL=None.
This commit removes the current help center markdown files and any logic
that was used to host those files at help/.
We also remove a bunch of tests, we should the equivalent of those tests
for the new help center. Issues to track: #35649, #35647. These issues
track adding back tests for redirects and broken links.
We had a symlink from templates/zerver/integrations/email.md pointing to
help/using-zulip-via-email.md. We can no longer have that symlink since
the latter has been converted to an MDX file. We have deleted the
symlink and put a markdown file in it's place. Both the files have
comments to edit the other in case of changes.
This commit also makes changes in astro config, astro component paths
and other places to move the starlight help center docs base path from
/starlight_help to /help.
The change to rename /starlight_help/ to /help/ in MDX files is done in
the next commit. If we squash these commits, this line should be
removed.
`./tools/build-help-center` no longer does the conversion step.
We also remove some dead code related to the old help center in
documentation.py.
zulip_groups is a special attribute, for the group sync feature, and
will always be read from the SAMLResponse if it's present and group sync
is enabled.
Listing it in extra_attrs is a misconfiguration that results in
confusing behavior. See #35787.
Contrary to what the comment implied, the remaining `fetch_tweet_data`
function would never return a cache hit, as it is namespaced by the
current deploy's cache key.
This commit adds an endpoint `/mobile_push/e2ee/test_notification`
to send an end-to-end encrypted test push notification to the user's
selected mobile device or all of their mobile devices.
This commit includes the following changes:
- Add an administrator setting to customize the Welcome Bot
message when sending an invitation.
- Add an API endpoint to test the customized Welcome Bot message
by sending a copy of the message to the administrator.
Fixes#27663.
Co-authored-by: Akarsh Jain <akarsh.jain.790@gmail.com>
The test cases are copied from ReorderCustomProfileFieldTest since we
are imitating the reordering mechanism from custom profile fields to
channel folders.
Fixes#20028.
There's no reason to have a special `RealmCreationKey` class - the
`Confirmation` system already does this job.
This is somewhat complicated by the need to write a migration for
`RealmCreationKey`->`Confirmation` for pre-existing, valid objects, to
avoid breaking realm creation links that haven't been used yet.
This commit replaces the `PUSH_NOTIFICATION_REDACT_CONTENT` server
setting with `require_e2ee_push_notifications` realm setting.
If `require_e2ee_push_notifications` set to True:
* Older clients: Content redacted
* Updated clients: Encrypted content
If `require_e2ee_push_notifications` set to False:
* Older clients: Content NOT redacted
* Updated clients: Encrypted content
Note: Older clients refers to clients that don't support E2EE.
Fixes part of #35370.
Due to the atomic(savepoint=False) here, an LDAP sync exception while
syncing a single user breaks the whole sync_ldap_user_data transaction,
preventing it from successfully syncing other users.
Fixes a regression introduced in
1eecbad381Closes#35291.
Some installations will change `dn` when a user marries, and also for
Active Directory and various other LDAP providers I've checked,
there's often a better value to use.
Uses the approach done for email change confirmations in #34980 to avoid
triggering a reactivation via just a GET request. Instead, the GET
should return a page which will trigger the browser to then POST the key
to the endpoint.
In 40956ae4c5 we implemented group sync
via SAML during sign in and sign up. The sign up implementation used a
session variable group_memberships_sync_map to plumb through the sync
information to the registration codepath, to execute group sync after
user creation.
We can use a more robust approach instead, and just amend groups on the
`PreregistrationUser` object that's going to be used for registration.
Adds support for syncing group memberships for a user when logging in
via SAML. The list of group memberships is passed by the IdP in the
zulip_groups SAML attribute in the SAMLResponse.
In user signup context, we are okay with there being an existing mirror
dummy user with the matching email - at the end of the signup, that
mirror dummy account will be activated and control of it given to the
user doing this signup.
However, in email change contexts (SCIM API and regular email change
flow), we can't change an account's email address to the address that
already belongs to an existing mirror dummy user.
To avoid subtle bugs like this, we make callers have to explicitly
specify whether existance of mirror dummies with the matching email
address is okay or not.
Just like with signup confirmation links, we shouldn't trigger email
change based on a GET to the confirmation URL - POST should be required.
So upon GET of the confirmation link, we serve a form which will
immediately be POSTed by JS code to finalize the email change.
The `push_registration_encryption_keys` map stores the
assymetric key pair generated on bouncer.
The public key will be used by the client to encrypt
registration data and the bouncer will use the corresponding
private key to decrypt.
- Updated the `generate_secrets.py` script to generate the map
during installation in dev environment.
- Added a management command to add / remove key i.e. use it
for key rotation while retaining the older key-pair for a period
of time.
When a user is added to a channel, we send
the user that was added a Notification Bot
DMs to let them know about it.
In this commit, we add an option for whether or not
this message is sent.
If more than 100 users are added at once, we
do not send notification bot DMs since it would
be a performance-costly operation.
We also send this threshold value of 100 in the
initial state data to the clients.
Fixes part of #31189
This pulls in changes from the latest django-jinja[^1]
`makemessages.py` monkey-patching. Specifically, it adds support for
`trimmed`, `notrimmed`, and the `ext.i18n.trimmed` policy. We enable
that, which removes unsightly and unnecessary whitespace inside of
`{% trans %}` blocks.
[^1]: aac828ca63/django_jinja/management/commands/makemessages.py
