Depending on the kind of config error being shown, different "go back"
links may be more appropriate.
We probably hard-coded /login/ for it, because these config errors are
most commonly used for authentication backend config error, where it
makes sense to have /login/ as "go back", because the user most likely
indeed got there from the login page.
However, for remote_billing_bouncer_not_configured, it doesn't make
sense, because the user almost surely is already logged in and got there
by clicking "Plan management" inside the gear menu in the logged in app.
Just shows a config error page if the bouncer is not enabled. Uses a new
endpoint for this so that it can work nicely for both browser and
desktop app clients.
It's necessary, because the desktop app expects to get a json response
with either an error or billing_access_url to redirect to. Showing a
nice config error page can't be done via the json error mechanism, so
instead we just serve a redirect to the new error page, which the app
will open in the browser in a new window or tab.
When a server doesn't submit a remote realm info which was
previously submitted, we mark it as locally deleted.
If such a realm has paid plan attached to it, we should investigate.
This commit adds logic to send an email to sales@zulip.com for
investigation.
This is a prep commit which replaces the 'invoice_overdue'
and 'reminder_to_review_plan' email templates with
'internal_billing_notice'.
This will help us to use the same template as we plan to
send an email to sales when a remote realm with paid plan
attached is locally deleted.
The (1) delay in fetching the read receipts data from the api call to
`/json/messages/${message_id}/read_receipts`; followed by the execution
of the success callback function, and the (2) use of `.append()` to
render the modal and user list, together lead to duplication of the read
receipts modal and also the user list inside the read receipts menu.
This commit adds a check to set the read receipts menu contents only if
the read receipts modal for the selected message ID is open by the time
the network request is resolved.
In addition, this commit also uses the `on_shown` hook instead of the
`on_show` hook in the read receipts modal logic, to add a delay in the
calling of the read receipts API, which prevents the stacking of the
requests.
For fixed-price plans, we send a reminder email to
sales@zulip.com, 2 months before the end date, to review
the pricing and configure a new fixed-price plan accordingly.
Instead of charging the customer using the attached payment
method and then creating the invoice, we create an invoice and
force an immediate payment for the invoice via the attached
payment method.
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.
Sahil Batra
Mateusz Mandera
Prakhar Pratyush
David Rosa
Sayam Samal
Alya Abbott
Aman Agrawal
Anders Kaseorg
Varun-Kolanu
Lauryn Menard
Tim Abbott
swayam0322
Alex Vandiver
afeefuddin
ecxtacy
Karl Stolley
Hemant Umre
Joelute
Daniil Fadeev
Satyam Bansal
evykassirer
Signior-X
Daniil Fadeev
evykassirer