As the help center article now has detailed instructions to generate
an incoming webhook URL, the integration documentation only needs to
link to that information.
The way the flow goes now is this:
1. The user initiaties login via "Billing" in the gear menu.
2. That takes them to `/self-hosted-billing/` (possibly with a
`next_page` param if we use that for some gear menu options).
3. The server queries the bouncer to give the user a link with a signed
access token.
4. The user is redirected to that link (on `selfhosting.zulipchat.com`).
Now we have two cases, either the user is logging in for the first time
and already did in the past.
If this is the first time, we have:
5. The user is asked to fill in their email in a form that's shown,
pre-filled with the value provided inside the signed access token.
They POST this to the next endpoint.
6. The next endpoint sends a confirmation email to that address and asks
the user to go check their email.
7. The user clicks the link in their email is taken to the
from_confirmation endpoint.
8. Their initial RemoteBillingUser is created, a new signed link like in
(3) is generated and they're transparently taken back to (4),
where now that they have a RemoteBillingUser, they're handled
just like a user who already logged in before:
If the user already logged in before, they go straight here:
9. "Confirm login" page - they're shown their information (email and
full_name), can update
their full name in the form if they want. They also accept ToS here
if necessary. They POST this form back to
the endpoint and finally have a logged in session.
10. They're redirected to billing (or `next_page`) now that they have
access.
For the last form (with Full Name and ToS consent field), this pretty
shamelessly re-uses and directly renders the
corporate/remote_realm_billing_finalize_login_confirmation.html
template. That's probably good in terms of re-use, but calls for a
clean-up commit that will generalize the name of this template and the
classes/ids in the HTML.
Use of `string_id` in the sponsorship request email content was
removed in commit d3834f8b9, but it is still used in the email
subject.
Updates the email subject to use the billing_entity_display_name,
which is still the Realm.string_id for Zulip Cloud organizations.
Sets this string as "billing_entity" in the context and subject
template.
The hidden logout form facilitates logging out from the app by providing
a form with the CSRF token required for the csrf_token protection in
Jinja2.
This commit moves this form from the ".app" div to the body,
where it is more appropriately placed in the DOM.
This is a prep commit for #27550.
Adds details about the requested organization URL and type to the
registration confirmation email that's sent when creating a new
Zulip organization.
Fixes#25899.
- Tweaks documentation and clarifies that the "Jitsi server URL"
setting is not just a server-side setting.
- Updates instructions to a series of steps to be followed directly,
without having to go to the help center.
Fixes#26907.
Updates the shared integrations documentation on generating a URL for
an incoming webhook for the new modal in the web-app, with links to the
help center. Also, links to a new section in the incoming webhooks
overview in the API documentation about the URL specification.
Also, adds a link to the help center in the shared webhooks integration
instructions for creating a stream for an incoming webhook. And updates
the example webhook URL to use a stream ID instead of a stream name.
In this commit, we add a new dropdown 'Organization language' on
the `/new` and `/realm/register` pages. This dropdown allows setting
the language of the organization during its creation. This allows
messages from Welcome Bot and introductory messages in streams to be
internationalized.
Fixes a part of #25729.
Adds a new onboarding email `onboarding_team_to_zulip` for the user
who created the new Zulip organization.
Co-authored by: Alya Abbott <alya@zulip.com>
These changes adds a new scheduled message indicator in conversation views
which informs the user of the number of messages that are scheduled to be
sent to the current view.
Fixes: #25584.
We used "btn-primary" class only in integrations dev panel page
and this commit re-adds the CSS applied by this class in
integrations_dev_panel.css. We also remove the btn-primary class
since this is a bootstrap-specific class and we no longer
need it.
We now use micromodal in the modal on dev server emails page to
make it consistent with other modals in the app and this is
preparatory work for moving away from bootstrap as well.
These selectors have been deleted because they were not being used
anywhere in '/templates/zerver/emails/**', and do not seem relevant
for send_custom_email custom emails that we might do manually.
Updates the contact_us_zulip_cloud and contact_us_self_hosted email
macros to have the "mailto" scheme in the anchor tag for the support
email address.
Also updates the Zulip Cloud version for the account_registered
support email link, which has a slightly different format/text than
the macro.
Rename existing shortened references to demo organizations, like
`is_demo_org` or `demo-org-warning`, that have been used in the
codebase so far and replace them to be like the `models.py`
variable: `Realm.demo_organization_scheduled_deletion_date`.
Creates process for demo organization owners to add an email address
and password to their account.
Uses the same flow as changing an email (via user settings) at the
beginning, but then sends a different email template to the user
for the email confirmation process.
We also encourage users to set their full name field in the modal for
adding an email in a demo organization. We disable the submit button
on the form if either input is empty, email or full name.
When the user clicks the 'confirm and set password' button in the
email sent to confirm the email address sent via the form, their
email is updated via confirm_email_change, but the user is redirected
to the reset password page for their account (instead of the page for
confirming an email change has happened).
Once the user successfully sets a password, then they will be
prompted to log in with their newly configured email and password.
Remove overflow: hidden from the body and overflow: auto from the
.markdown element. Adjust the scroll-margin-top on the heading
elements so that using the hash, the page opens at perfect
location. Add position: fixed to .sidebar so that it does not scroll
with the content.
For the mobile view, change the .sidebar right from 100vw to 100%.
Also change how the hamburger menu changes its position: use right
instead of left as that works better than translate combined with
left.
The "followup_day2" email template name is not clear or descriptive
about the purpose of the email. Creates a duplicate of those email
template files with the template name "zulip_onboarding_topics".
Because any existing scheduled emails that use the "followup_day2"
templates will need to be updated before the current templates can
be removed, we don't do a simple file rename here.
The "followup_day1" email template name is not clear or descriptive
about the purpose of the email. Creates a duplicate of those email
template files with the template name "account_registered".
Because any existing scheduled emails that use the "followup_day1"
templates will need to be updated before the current templates can
be removed, we don't do a simple file rename here.
This commit renames "dialog_cancel_button" class in the exit button
of modals to "dialog_exit_button", which seems a much better name
for a button that is used to close a modal.
This commit completes the notifications part of the @topic
wildcard mention feature.
Notifications are sent to the topic participants for the
@topic wildcard mention.
This commit re-adds bootstrap CSS for search input in
integrations page using a more specific selector in
integrations.css. We also change the selector to use
a class name instead of "input".
This is a prep commit for removing bootstrap CSS for text type
inputs.
This prep commit replaces the 'wildcard' keyword in the codebase
with 'stream_wildcard' at some places for better readability, as
we plan to introduce 'topic_wildcards' as a part of the
'@topic mention' project.
Currently, 'wildcards = ["all", "everyone", "stream"]' which is an
alias to mention everyone in the stream, hence better renamed as
'stream_wildcards'.
Eventually, we will have:
'stream_wildcard' as an alias to mention everyone in the stream.
'topic_wildcard' as an alias to mention everyone in the topic.
'wildcard' refers to 'stream_wildcard' and 'topic_wildcard' as a whole.
The emails sent for missed messages have a text at the bottom
explaining the reason why the email was sent.
This commit reorders the conditional statements in the email
template to align with the trigger priority order defined
in the 'get_email_notification_trigger'.
This commit updates the text on email confirmation page to
make it more clear what's going on and why the user needs
to check their email.
Fixes#25900.
This commit makes it possible for users to control the wildcard
mention notifications for messages sent to followed topics
via a global notification setting.
There is no support for configuring this setting
through the UI yet.
This commit makes it possible for users to control
the email notifications for messages sent to followed topics
via a global notification setting.
Although there is no support for configuring this setting
through the UI yet.
Add five new fields to the UserBaseSettings class for
the "followed topic notifications" feature, similar to
stream notifications. But this commit consists only of
the implementation of email notifications.
Apparently, Apple Mail interpreted the <body> text in the comment here
as the start of the body in the email in its special parser for
displaying a preview of emails in the inbox view, resulting in every
Zulip email being displayed as "tag out of the email, the ..." instead
of our configured preheader.
This is how other overlays are managed, and will be important in
upcoming refactoring, since we don't want the overlay height to be
restricted by the height of the `.app`.
We now allow users to change email address visibility setting
on the "Terms of service" page during first login. This page is
not shown for users creating account using normal registration
process, but is useful for imported users and users created
through API, LDAP, SCIM and management commands.
This commit changes the title of page to "Welcome to Zulip"
and submit button text to "Continue". We do this change because
same page will be used to allow users to set email address
visibility during first login even when organization has not
configured terms of service and we can avoid using conditionals
now by using this title and submit button text.
This commit extracts html for setting new user email address
visibility in the registration page to a separate file.
This new file will then be used to allow imported users set
email visibility during login without having to duplicate the
code.
This commit extracts html for modal used for changing email
address visibility during registration to a separate file
so that we can avoid code duplication when we add commits
to allow changing email address visibility for imported
users during login.
Previously, the unread banner templates just rendered on the contents of
the unread banner. This works fine if we don't want to make changes towards
the parent/container of the contents.
This change introduces a new container to each unread banner templates and
a rename. Thus, we can make unique styling changes to the unread banners
while also bring the structure closer to how it is for compose banners.
We add bootstrap anchor tag styles in our main `index.html` page so
that the link styles are always applied on the reload link and it looks
like a link.
Fixes#25377.
The "Resend" link for realm creation was not working correctly
because it is implemented by basically submiting the registration
form again which results in resending the email but all the
required parameters were not passed to the form after recent
changes in the realm creation flow.
This commit fixes it by passing all the required parameters -
email, realm name, realm type and realm subdomain, when submitting
form again by clicking on the "resend" link.
Fixes#25249.
This commit places the email CSS into the `style` tag located in the
`head` section. This resolves the issue of being unable to apply
certain CSS styles that cannot be inlined, such as media queries and
pseudo-classes.
In #23380 we want to change all occurrences of `uri` with `url`.
This commit changes the occurrences in a context key `api_uri_context`
and a function name `add_api_uri_context`.
In #23380 we want to change all occurrences of `uri` with `url`.
This commit changes the names of two variables `external_uri_scheme`
and `main_site_uri`, who are constructed using `settings` constants.
In #23380 we want to change all ocurrences of `uri` to `url`. This
commit changes the ocurrences of `uri` appeared in files related to
email, including templates (`.html`, `.txt`) and backend (`.py`)
codes.
In `email.md`, `base_images_uri` is changed to `images_base_url` -
the words `base` and `images` are swapped and plural form is added
for `image`. This is becasue the former is not found anywhere in
the codebase while the later appears a lot. To reduce confusion,
this doccumentation changed accordingly.
Adds CSS formatting for `invalid_email.html`.
Uses the `white-box` style because this page is a redirect when
there is an error with the email the user provided during
registration.
Also, updates the text of this page for some grammar errors and
to clarify the language between an invalid email and an email that
is not allowed by the Zulip organization in question.
Finally, makes any references to the `realm_name` also link to
the Zulip organization with the `realm_uri`.
Adds CSS formatting for `no_spare_licenses.html`.
Uses the `white-box` style because this page is a redirect when
a user tries to register for a Zulip Cloud organization that does
not have any available licenses for new users.
Updates reference to `realm_name` to be a link to the `realm_uri`.
Adds CSS formatting for `unsubscribe_link_error.html`.
Uses the `white-box` style because this page is a redirect when
there is an error when processing an unsubscribe email link.
The migration to css-inline "fixed" the fact that styles from this
file previously were never applied to the internals of missed-message
emails.
Rewrite much of the CSS to more correctly scope to apply to the
appropriate elements, and document with comments the purpose of most
blocks.
Co-authored-by: Tim Abbott <tabbott@zulip.com>
Adds the `account-creation` class to `<div>` tag in template so that
the associated CSS styles for `white-box p:last-of-type` and the
font-weight are applied.
Previously, the email had a line that says "Click the button below". This
sounds weird as the plain text emails don't have buttons and only had links.
We should change "Click the button below" to "Click the link below" which
makes more sense.
After merging #24423, it was found that there were still an email yet to be updated with the new lines introduced in that PR. This commit updates both the email and plain-text versions.
This is a continuation of #24260 where we have redrafted the "contact us"
line in various emails, but the plain-text versions of those emails remains
untouched. We want to also update those versions and ensure that they match
with our emails.
Fixes: #25198.
Several onboarding emails sent to new users/organizations used the
same "contact us" language. Adds new macros for the "contact us"
line for Zulip Cloud and self-hosted realms to eliminate repetition.
The suitable macro for Zulip Cloud vs self-hosted organizations is
decided conditionally, by checking corporate_enabled.
Fixes#24260.
This commit renames ID of the container element of group
settings overlay to group_overlay_container. We also
rename the variables used for this element. This makes
it consistent with the container element of settings overlay.
This commit renames ID of the container element of stream
settings overlay to streams_overlay_container. This makes
it consistent with the container element of settings overlay.
Because unsubscribing from welcome emails cannot be undone, it is
confusing that the unsubscribe success page suggests that the user
can. Makes the second sentence about undoing the unsubscribe action
conditional on the `subscription_type` not being "welcome".
Updates the first sentence to specifically note the Zulip realm
that has been updated for the unsubscribe action so that it is
clear for which Zulip organization the user's settings have been
updated/changed, since the user might have accounts with various
Zulip organizations (via Zulip Cloud or self-hosted servers) that
use the same email account.
If the script comes from a different origin than the requesting page,
and is not marked `crossorigin="anonymous"`, the `window.onerror`
handler receives no information other than "Script error." in the
event of a runtime error.
This effectively silences blueslip errors in development if the user
is developing on a remote host (such as a DigitalOcean droplet), since
static resources are served from `hostname.zulipdev.org`, and the
realm is served from `realmname.hostname.zulipdev.org`. It also
silenced blueslip reporting in production for any non-default (non-"")
realms. Sentry reporting, Vagrant developments, and truly ancient or
insecure browsers were unaffected.
Add the necessary `crossorigin="anonymous"` attribute to the
`<script>` tag to allow blueslip access to this error information.
This issue was introduced after we changed the library we use for
inlining CSS into email HTML. For some reason, the styles in
email.css were not applied earlier but were applied after we
migrated to css-inline. With this commit, we have fixed the
regression in background-color of email body.
Fixes#25083.
This issue was introduced after we changed the library we use for
inlining CSS into email HTML. For some reason, the styles in
email.css were not applied earlier but were applied after we
migrated to css-inline. With this commit, we have fixed the
regression in footer styles.
Fixes part of #25083
Per the issue #25045, this commit changes some occurences of `uri`
appeared in variable `root_domain_uri`. Files affected are some
html files that used this variables and a backend file
`context_processors.py` that set it as a key.
Adds a new welcome email, `onboarding_zulip_guide`, to be sent four
days after a new user registers with a Zulip organization if the
organization has specified a particular organization type that has
a guide in the corporate `/for/.../` pages. If there is no guide,
then no email is scheduled or sent.
The current `for/communities/` page is not very useful for users
who are not organization administrators, so these onboarding guide
emails are further restricted for those organization types to
only go to new users who are invited/registered as admins for the
organzation.
Adds two database queries for new user registrations: one to get
the organization's type and one to create the scheduled email.
Adds two email logs because the email is sent both to a new user
who registers with an existing organization and to the organization
owner when they register a new organization.
Co-authored by: Alya Abbott <alya@zulip.com>
Previously, we had an architecture where CSS inlining for emails was
done at provision time in inline_email_css.py. This was necessary
because the library we were using for this, Premailer, was extremely
slow, and doing the inlining for every outgoing email would have been
prohibitively expensive.
Now that we've migrated to a more modern library that inlines the
small amount of CSS we have into emails nearly instantly, we are able
to remove the complex architecture built to work around Premailer
being slow and just do the CSS inlining as the final step in sending
each individual email.
This has several significant benefits:
* Removes a fiddly provisioning step that made the edit/refresh cycle
for modifying email templates confusing; there's no longer a CSS
inlining step that, if you forget to do it, results in your testing a
stale variant of the email templates.
* Fixes internationalization problems related to translators working
with pre-CSS-inlined emails, and then Django trying to apply the
translators to the post-CSS-inlined version.
* Makes the send_custom_email pipeline simpler and easier to improve.
Signed-off-by: Daniil Fadeev <fadeevd@zulip.com>
- Being more specific about what the user will get.
- Putting less emphasis on entering multiple emails, since most
people probably just have one email they need to check.
- Using more intuitive wording and hint that deactivated or
deleted accounts won't be included.
Fixes: #24890.
In previous commits, we updated the realm creation flow to show
the realm name, type and subdomain fields in the first form
when asking for the email of the user. This commit updates the
user registration form to show the already filled realm details
as non-editable text and there is also a button to edit the
realm details before registration.
We also update the sub-heading for user registration form as
mentioned in the issue.
Fixes part of #24307.
We now show inputs for realm details like name, type and URL
in the create_realm.html template opened for "/new" url and
these information will be stored in PreregistrationRealm
objects in further commits.
We add a new class RealmDetailsForm in forms.py for this
such that it is used as a base class for RealmCreationForm
and we define RealmDetailsForm such that we can use it as
a subclass for RegistrationForm as well to avoid duplication.
This commit extracts realm creation form html in a new file
realm_creation_form.html as we are reworking the organization
flow as per #24307 and this change would allow us to avoid
duplicating the code.
This commit updates the ID for form element in create_realm.html
to "create_realm" as we would need to update the error handling
for this page in further commits and we do not want to break it
for other forms using "send_confirm" as ID.
The string "Or import from Slack, Mattermost, Gitter, or
Rocket.Chat." in create_realm.html was not tagged for
translation before. This commit fixes it to tag the string
for translation.
`render_markdown_path` renders Markdown, and also (since baff121115)
runs Jinja2 on the resulting HTML.
The `pure_markdown` flag was added in 0a99fa2fd6, and did two
things: retried the path directly in the filesystem if it wasn't found
by the Jinja2 resolver, and also skipped the subsequent Jinja2
templating step (regardless of where the content was found). In this
context, the name `pure_markdown` made some sense. The only two
callsites were the TOS and privacy policy renders, which might have
had user-supplied arbitrary paths, and we wished to handle absolute
paths in addition to ones inside `templates/`.
Unfortunately, the follow-up of 01bd55bbcb did not refactor the
logic -- it changed it, by making `pure_markdown` only do the former
of the two behaviors. Passing `pure_markdown=True` after that commit
still caused it to always run Jinja2, but allowed it to look elsewhere
in the filesystem.
This set the stage for calls, such as the one introduced in
dedea23745, which passed both a context for Jinja2, as well as
`pure_markdown=True` implying that Jinja2 was not to be used.
Split the two previous behaviors of the `pure_markdown` flag, and use
pre-existing data to control them, rather than an explicit flag. For
handling policy information which is stored at an absolute path
outside of the template root, we switch to using the template search
path if and only if the path is relative. This also closes the
potential inconsistency based on CWD when `pure_markdown=True` was
passed and the path was relative, not absolute.
Decide whether to run Jinja2 based on if a context is passed in at
all. This restores the behavior in the initial 0a99fa2fd6 where a
call to `rendar_markdown_path` could be made to just render markdown,
and not some other unmentioned and unrelated templating language as
well.
Currently, there is a checkbox setting for whether to
"Include realm name in subject of message notification emails".
This commit replaces the checkbox setting with a dropdown
having values: Automatic [default], Always, Never.
The Automatic option includes the realm name if, and only if,
there are multiple Zulip realms associated with the user's email.
Tests are added and(or) modified.
Fixes: #19905.
Lauryn Menard
Anders Kaseorg
Aman Agrawal
Alya Abbott
Tim Abbott
Karl Stolley
Mateusz Mandera
Sayam Samal
Alex Vandiver
David Rosa
Hemant Umre
Sahil Batra
Joelute
Daniil Fadeev
Satyam Bansal
evykassirer
Signior-X
Daniil Fadeev
evykassirer
Prakhar Pratyush
Lalit
AcKindle3
Ujjwal Aggarwal
Josh Klar
