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>
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.
Clears up some naming confusion - `REALM_CREATION_LINK_VALIDITY_DAYS` is
a setting which describes the validaty period of RealmCreationKey, not
of Confirmation with REALM_CREATION type. Now that the latter is called
NEW_REALM_USER_REGISTRATION, there should be no confusion about this.
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.
Having a logger object will be helpful in the upcoming commit to pass as
argument to sync_groups. We use the root logger here (sticking to
original behavior) rather than setting up `getLogger(__name__)` to avoid
breaking a large number of tests which assert logs content - as there
doesn't seem to be any major upside to using a separate logger for this
file.
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.
When selecting the realm owner is not needed in the realm creation from
Slack flow, we don't set need_select_realm_owner value on the
preregistration_realm object. Thus, this codepath cannot expect to
always find the key - and instead should use .get(), defaulting to False.
Creating a demo organization will not require the user to
set either an email or password, so explicitly set the
password field to not be required for that case.
Updates the form submitted in the dev environment to create
a new demo organization to not send a password value.
Zulip supports a configuration where account creation is limited solely
by being able to authenticate with a single-sign on authentication
backend, such as Google Authentication, SAML, or LDAP (i.e., the
organization places no restrictions on email address domains or
invitations being required to join, but has disabled the
EmailAuthBackend that is used for email/password authentication).
A bug in the Zulip server meant that Zulip allowed users to create an
account in such organizations by confirming their email address, without
having an account with the SSO authentication backend.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
We need `corporate_enabled` and some other params to render
500 error page which is not passed when using `server_error`,
as it only contains our custom inserted `DEFAULT_PAGE_PARAMS`.
We render the page with `zulip_default_context` to fix this.
If there were no users found for `find_team`, we need to provide
a default langauge for the email as one cannot be extracted from
`UserProfile` in this case.
This commit allows users to be assigned to custom groups when
inviting them to join Zulip, similar to how channels are handled.
The implementation follows a similar pattern for adding pills,
ensuring consistency, as user groups and channels are parallel
in nature.
Fixes#24365.
Aside of what's generally explained in the code comment, this is
motivated by the specific situation of import of Slack Connect channels.
These channels contain users who are "external collaborators" and
limited to a single channel in Slack. We don't have more sophisticated
handling of their import, which would map this concept 1-to-1 in Zulip -
but we create them as inactive dummy users, meaning they have to go
through signup before their account is usable.
The issue is that their imported UserProfile.role is set to Member and
when they register, the UserProfile gets reactivated with that role
unchanged. However, if e.g. the user is signing up after they received
an invitation from the admin, they should get the role that was
configured on the invite. In particular important if the user is meant
to still be "limited" and thus the admin invites them as a guest - they
definitely don't want the user to get a full Member account because of
this weird interaction between import and registration.
This commit adds include_realm_default_subscriptions parameter
to the invite endpoints and the corresponding field in
PreregistrationUser and MultiuseInvite objects. This field will
be used to subscribe the new users to the default streams at the
time of account creation and not to the streams that were default
when sending the invite.
In #23380, we are changing all occurrences of uri with url in order to
follow the latest URL standard. Previous PRs #25038 and #25045 has
replaced the occurences of uri that has no direct relation with realm.
This commit changes just the model property, which has no API
compatibility concerns.
Previously, users were allowed to signup or change their names to
those which already existed in the realm.
This commit adds an Organization Permission, that shall enforce
users to use unique names while signing up or changing their
names. If a same or normalized full name is found in realm,
then a validation error is thrown.
Fixes#7830.
Previously, email addresses that weren't connected to a Zulip account
were ignored but now they receive an email stating their email isn't
connected to a Zulip account.
Also, removes the "Thanks for using Zulip!" line at the end of the
find accounts email that's sent when a Zulip account is found.
Updates the i18n test that used this string with another in the
German translation from this a successful account found email.
Fixes part of #3128
Co-authored-by: Lauryn Menard <lauryn@zulip.com>
Updates the help link in the find team emails to use the external
host information.
Removes the link for the external host since the realm links are
what the user should click on to login.
Also, passes corporate_enabled to the find team email to adjust
the text for Zulip Cloud emails.
Earlier, after a successful POST request on find accounts page
users were redirected to a URL with the emails (submitted via form)
as URL parameters. Those raw emails in the URL were used to
display on a template.
We no longer redirect to such a URL; instead, we directly render
a template with emails passed as a context variable.
Fixes part of #3128
