Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Closes#35196.
In #34850 we implemented this for the ldap authentication codepath.
This PR makes it support also during the sync_ldap_user_data job.
What this means practically is that if this functionality is enabled and
correctly configured, sync_ldap_user_data is able to find the associated
user in the ldap directory even if the email value in the directory has
changed. The UserProfile's delivery_email will be updated to sync this
change, in addition to the regular syncing for other attributes.
Email changes used to break the association between UserProfile and the
ldap user entry.
The primary challenge making this implementation fairly complex is the
fact that django-auth-ldap is designed with authentication in mind, so
it doesn't make arbitrary LDAP searches easy - and the regular direction
is:
user ldap credentials -> LDAP user data -> Django user object.
However, the sync job searches in the opposite direction. We begin with
a Django UserProfile - we need to find the ExternalAuthID entry (if it
exists), and then based on the configuration of this feature, do an
appropriate LDAP search to find the LDAP user entry with the matching
value in the attribute configured as the `unique_account_id`.
4c3aa4c007 migrated the GET
/users/{user_id_or_email}/presence endpoint to return only the modern
format (active_timestamp and idle_timestamp). The assumption that the
endpoint had no significant consumers turned out to be wrong: the
Zulip web app itself was a consumer (in user_card_popover, where it
caused a "Failed to parse presence API response" error for any
currently active user), and there are likely third-party integrations
relying on the legacy format as well.
Restore the legacy website and aggregated dictionaries alongside the
new modern fields, so existing clients keep working. Clients should
migrate to the modern fields, which is now phrased as a recommendation
rather than a breaking change in the API and self-hosted upgrade
notes.
Additionally, add a top-level server_timestamp field to the response,
matching the behavior of other presence endpoints. This lets clients
compute presence-status age against the server's clock rather than
guessing with the local clock.
Refactor the view to query UserPresence once and format both the
modern and legacy presence dicts from the same row, rather than
issuing two queries that fetch the same data.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
If a realm has owner_full_content_access set to True and the current
user is an owner, the standard export should be full without consent.
For realms with owner_full_content_access set to True, the option to do
a full export with consent will not be available for owners. The option
will still be available to admins.
We also rename the options in this commit to be more clearer since
standard was a vague term. Having these new option names makes the
explanation for the export types redundant, so we remove it.
Co-authored-by: Alya Abbott <alya@zulip.com>
Revises the existing API documentation pages for incoming webhooks,
and adds it to the developer documentation at RTD.
Preparation for removing this content from the API documentation,
and redirecting those pages to the new RTD pages.
Co-authored-by: Alya Abbott <alya@zulip.com>
Co-authored-by: Niloth P <20315308+Niloth-p@users.noreply.github.com>
We redirect existing URLs to the new URLs. We want to use
`/integrations/category/{category_slug}` for categories and
`/integrations/{integration_name}` instead of
`/integrations/doc/{integration_name}` for individual integrations page.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
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 needs explanation both in upgrade notes and in the main
documentation for mobile push notifications.
Co-authored-by: Prakhar Pratyush <prakhar@zulip.com>
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.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
