It appears the plans page version of this had a less clear/specific
list of example communities than was intended. Also improve the longer
version in the Help Center to give the same examples.
If server has plan, deny login for realm.
If realm has plan, deny login for server.
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Co-authored-by: Alya Abbott <alya@zulip.com>
Also avoid prompting for full name time more than once.
Adds TOS version field to Remote server user.
Co-authored-by: Karl Stolley <karl@zulip.com>
Co-authored-by: Aman Agrawal <amanagr@zulip.com>
Adds three columns to the remote server activity chart and updates
the chart key for the third of those columns.
The first is the plan name. If there are multiple plans with a
status under the live threshhold, then we send "See support view".
The second is the plan status. If there are multiple plans, then
we send "Multiple plans".
The third is the estimated annual revenue for the plan. Note that
for free trials, this will be calculated as if the plan was paid
for 12 months (so a full year).
If there is no plan for the server under the live threshold or at
all then "---" is inserted into the table row. Note that 100%
sponsored servers/realms would fall into this category.
This is a general link for logging into the billing system on behalf of
a server, but it's tied to the .contact_email and takes the user
straight to the /deactivate/ page via the next_page mechanism.
Pulls the forms for updating the billing collection method and
generally modifying the current plan to a separate template.
Uses the shared template to render these forms for both the
remote server and any attached remote realms.
If there are remote realms attached to the remote server, adds
the forms to be able to update sponsorship requests, approve
sponsorship and update a discount.
When a self-hosted Zulip server does a data export and then import
process into a different hosting environment (i.e. not sharing the
RemoteZulipServer with the original, we'll have various things that
fail where we look up the RemoteRealm by UUID and find it but the
RemoteZulipServer it is associated with is the wrong one.
Right now, we ask user to contact support via an error page but
might develop UI to help user do the migration directly.
The separation of files no longer makes any sense, with some of these
forms being used by the RemoteRealm and legacy server flows together.
And in general we don't need to scatter this stuff across files.
Also, the unifying of the class of loader on the buttons, fixes a visual
bug on the final "Confirm login" page where you would see it spinning
for half a second upon loading the page, until the .hide() code
triggered.
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.
* Reformat "This is a legacy plan" notice on billing page.
* Add a link to the plan name on upgrade page title.
* Tweak discount style on billing page.
* Add line break to server login page title.
* Match server login page title and tab title.
* For free trial, don't show number of licenses for current billing period.
* For free trial scheduled to downgrade, don't show number of
licenses for next billing period.
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.
Moves the section in support views for any current plan details
to a new template: `templates/analytics/current_plan_details.html`.
Also, updates the PlanData dataclass to have a boolean that checks
if the current plan tier is the self-hosted legacy plan.
Updates `get_plan_type_string` for RemoteZulipServer plan types and
capitalizes the strings used for Realm plan types.
Also changes the string for Realm.PLAN_TYPE_STANDARD_FREE to be
"Standard free" instead of "open source" as that is used for any
100% sponsored organization, which is not restricted to open-source
projects.
This adds the new tabs from /plans to:
* /for/business
* /self-hosting
And it isolates legacy styles to preserve the tabs on
/for/education
Fixes: #28013
Removes the support actions for changing a remote server's default
discount and sponsorship pending states if the remote server is on
the sponsored plan type.
The "send_invoice" and "charge_automatically" strings used by stripe
for the `collection_method` are referred to both as the "billing
method" and "billing modality" in the billing code.
Because we send this as data to stripe as either `collection_method`
or `billing_modality`, renames any references that are any form of
"billing method".
Analogical to 1df8e00d7c which implemented
this for the RemoteRealm auth flow.
Except here we don't need to add next_page to the IdentityDict
(LegacyServerIdentityDict in this flow), because the redirect happens
immediately at remote_billing_legacy_server_login upon login - so no
need to have a structure to carry the info through intermediate steps.
[squash]: Update sponsorsip and question boxes for Cloud.
[squash]: Update tabs subtitles.
[squash]: Content for info boxes for self-hosted plans.
[squash]: Adjust content to fit design.
portico: Tweak /plans text.
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.
This makes it possible for a self-hosted realm administrator to
directly access a logged-page on the push notifications bouncer
service, enabling billing, support contacts, and other administrator
for enterprise customers to be managed without manual setup.
If the update / add card session is successful, return user to
manual license management page if user was on it before clicking
the add / update card button.
This calculates the largest amount of messages sent within a month for
the last 3 months. The query is targeted for the specific use-case in
this function - for finding the count for a specific server. For
calculating this in bulk for a large number of remote server an
adapted, bulk query will be needed - rather than running this one in a
loop, which would likely be very inefficient.
- 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 do not redirect to Zulip's billing page for confirmation
even when user did not had added a card already and the payment
is directly processed after adding a card so is better to just
rename the button.
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.
We now use micromodal in the license update modal on billing page
to make it consistent with other modals in the app and this is
preparatory work for moving away from bootstrap as well.
Moves the "Remote Zulip servers" tab in the "/activity" page for
an installation to a separate page, "/activity/remote".
Prototype for moving other tabs in "/activity" to separate pages.
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 re-adds required bootstrap CSS rules defined with
"table-bordered" class to the specific files.
This is a prep commit to remove bootstrap CSS for tables.
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.
This commit ensures that the Attribution, Jobs, and Team pages all
share a uniform structure to match those of other pages. This will
simplify styling and should ensure greater confidence when modifying
portico landing-page styles.
The one CSS modification here, for the jobs page, maintains the space
at the top of the "How we work" section.
These classes seem to have been copy-pasted from other portico pages
when styling was first done in
122dcc9760. With the current styles,
which are just a handful of rules not scoped to a specific page, it
just makes the billing pages look broken.
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.
exempt_from_license_number_check was initially added allowing
organizations with it enabled to invite new users above their number of
licenses.
However, an organization with this permission enabled,
cannot upgrade if they weren't on a plan already - because when choosing
Manual license management, you cannot enter a number of licenses lower
than the current seat count. However, an organization like that probably
already has some users that they get free of charge - and thus they need
to be able to enter a lower number of licenses in order to upgrade.
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.
This just replaces the billing/upgrade with the statement that
"Your organization has requested sponsored or discounted hosting.", so
it should include an obvious contact in case the customer wants to amend
something or just bump a request that may have gotten missed.
Previously this was only available on the upgrade page - meaning an
organization that already bought a plan wouldn't be able to request a
sponsorship to get a discount or such, even if qualified.
Aman Agrawal
Tim Abbott
Alya Abbott
Karl Stolley
Karl Stolley
Alya Abbott
Lauryn Menard
Mateusz Mandera
Sayam Samal
Alex Vandiver
David Rosa
Hemant Umre
Sahil Batra
Joelute
Lauryn Menard
Daniil Fadeev
Anders Kaseorg
Satyam Bansal
evykassirer
Ujjawal Modi
Signior-X
Greg Price
Daniil Fadeev
evykassirer
Prakhar Pratyush
Lalit
AcKindle3
alik-balika
Ujjwal Aggarwal
Josh Klar
