Adds a support action for updating the minimum licenses on a
customer object once a default discount has also been set.
In the case that the current billing entity has a current active
plan or a scheduled upgrade to a new plan, then the minimum
licenses will not be updated.
Since the latest end time for reported active users on a remote
server is not used to determine if a remote server has current
data for billing purposes, we instead display the last audit log
update datetime for the remote server object.
Removes the note in the remote activity key about the Zulip
version.
Also adds a sum in the total row for mobile push notifications
sent.
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.
Changes the emoji that highlights when a remote realm or server has
an active discount.
Adds a remote server UUID field to the remote server information.
Moves the 'has remote realms' field to be after the Zulip version
information, and adds an extra break there to visually highlight
that field as well as the following 'max monthly messages' field.
In the remote server information displayed in the remote support
view, show the Zulip version currently on the RemoteZulipServer
object as last_version.
Also fixes formatting for per license price and moves the billing
schedule to be above this line so that it's clearer the per license
price is based on the billing schedule.
Moves the note about being on the sponsored Community plan to be
under the remote server or realm name.
Adds a note about a remote server or realm with a partial discount
set, which is another type of sponsorship.
Highlights these notes visually with emojis for support admin.
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.
Aman Agrawal
Karl Stolley
Alex Vandiver
Lauryn Menard
Alya Abbott
Anders Kaseorg
Tim Abbott
Karl Stolley
Alya Abbott
Mateusz Mandera