Adds a line to the top of the internal_billing_notice email with
the billing entity's display name.
Makes sure all internal_billng_notice email subjects also include
the billing entity's display name.
Makes small updates to the notice text for some cases.
We redesign the message history modal to make it look similar to the
drafts and scheduled messages, using the shared styling/rendering
logic for that those existing elements to have a less goofy widget.
Fixes#28695.
This commit updates the placeholder for name input in account
creation form to "Your full name".
We also removes the "名前" since that confuses the user who
do not know the language. This text was originally added to
indicate that the name field supports unicode characters, which
most modern apps do currently, so there is no need to add this
text in the placeholder.
Fixes part of #29226.
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.
Lauryn Menard
Mahhheshh
Sahil Batra
Mateusz Mandera
Prakhar Pratyush
David Rosa
Sayam Samal
Alya Abbott
Aman Agrawal
Anders Kaseorg
Varun-Kolanu
Tim Abbott
swayam0322
Alex Vandiver
afeefuddin
ecxtacy
Karl Stolley