When we are upgrading a customer to a different plan tier, we should
check if switching plans would lead to different licenses due to
different minimum license requirement between plans.
Updates the name for the self-hosted complimentary access plan
to "Zulip Basic (complimentary)" instead of "Free (legacy plan)".
Since these plans are never billed in Stripe, we don't need to
hold to the 22 character limit for the plan name.
Updates support actions for "temporary courtesy" plans to instead
use "complimentary access" to refer to these plans and actions.
Prep for implementing a complimentary access plan for Zulip Cloud.
Renames migrate_customer_to_legacy_plan to
create_complimentary_access_plan for how this
function is currently used.
Prep for adding a complimentary access plan
for Zulip Cloud.
Renames context variables used for the pricing model template for
when the customer has a current plan that has an upgrade to a new
plan tier scheduled.
Fixes the "Upgrade scheduled" note that was being shown when an
annual fixed-price plan has a subsequent fixed-price plan scheduled
to start when the current plan ends.
Prep for adding a complimentary access plan for Zulip Cloud.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
If the customer has a current fixed-price plan and a support admin
configures a fixed-price plan for the upcoming billing year, then
a CustomerPlan object is created and not a CustomerPlanOffer.
Fix the support action for deleting a configured fixed-price next
plan.
Updates the success strings for these actions to be specify if the
deleted object was a plan offer or a scheduled plan.
If we move a paid plan from a remote server to a remote realm, and
the plan has automated license management, then we create an updated
license ledger entry when we move the plan for the remote realm
billing data so that we have an accurate user count for licenses
when the plan is next invoiced.
In commit ea863bab5b, handle_customer_migration_from_server_to_realm
was updated to only move a remote server's plan in the case that there
is only one remote realm on the server.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Now visiting `/customer_portal` will correctly take you to the stripe
customer portal corresponding to the customer for editing.
There is no reason for us to block access to this page.
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
Renames should_schedule_upgrade_for_legacy_remote_server parameter
to upgrade_when_complimentary_access_plan_ends in both
process_initial_upgrade and compute_plan_parameters, as well as
associated variable names and relevant code comments.
Renames the remote_server_legacy_plan parameter in
process_initial_upgrade to instead be complimentary_access_plan,
as well as some relevant code comments in that function.
Adds COMPLIMENTARY_PLAN_TIERS to the CustomerPlan model so that
we start transitioning from the "legacy plan" language in the
billing system code. Adds a helper function that checks if the
plan tier is in COMPLIMENTARY_PLAN_TIERS.
Updates the sponsorship page context to use that helper function
and updates the relevant template for the updated user-facing
terminology.
Renames add_sponsorship_info_to_context to instead be
add_org_type_data_to_sponsorship_context since this function for
all billing entities is adding information about the organization
type for the sponsorship request form.
Being on a free trial also means that the billing entity is on a
paid plan.
If they are on a sponsored plan, then they are not on a free trial.
If they have a pending sponsorship request, then they will be
redirected to the billing page. Otherwise, they will be shown the
form to request a sponsored/discounted plan, which does not use
the free_trial boolean.
Reorders the logic in get_sponsorship_request_context so that the
early return for billing entities with a pending sponsorship request
that are also on a current paid plan is clearer.
Updates get_plan_data_for_support_view to get the latest ledger entry
directly instead of calling make_end_of_cycle_updates_if_needed so
that viewing a support page doesn't trigger any changes to the
current and scheduled plans.
Updates next_invoice_date since, as of commit caba57fe1e, we no
longer consider the plan's billing schedule (annual or monthly)
when invoicing for additional licenses.
Adds ability to configure a fixed-price plan and to delete a
configured fixed-price plan in the Cloud support view.
Updates the invoice processing to send reminder emails to the
billing support email for these Cloud fixed-price plans about
renewals since we now are able to configure them via our support
panel.
Updates function to get the billing session for stripe webhook
events to handle an intial upgrade for a custom generated invoice
for a fixed-price plan for a Cloud organization, which won't have
a user_id in the invoice metadata.
This check made sense before the support view expanded with the
billing system work over this past year. As we continue to expand
the actions/features of the support views, it's likely we'll have
cases where we're passing more values for particular features.
Prep for implementing fixed-price plan offers in Cloud support view.
Many of the templates for the remote and Cloud support views are
designed to be shared, but some features/actions have not yet been
implemented for both types of support views.
Adds a remote_support_view boolean to each type of support view
context so that it's easy to add checks to existing templates.
Updates the Cloud support view to use the current_plan_forms_support
template, and fixes existing bug of offering the upgrade to Plus
option for modifying a Cloud plan when the current plan is a
fixed-price plan.
Prep for implementing fixed-price plan offers in Cloud support view.
This commit adds a custom rule to check python files
and raise lint error if they have transaction.atomic used
without any argument or savepoint=True is used.
It helps to avoid creating unintended savepoints in the future.
For cases where a customer is created in Stripe first for the manual
invoice, we want to connect that customer information to our Customer
object in the database. That way the customer can access the billing
page once the invoice is paid.
Python parameter defaults are only evaluated once at the function
definition site, not at each call site. So these defaults were
incorrectly evaluating to the server’s startup time rather than the
current time.
Signed-off-by: Anders Kaseorg <anders@zulip.com>
Zulip production suite / ${{ matrix.name }} (zulip/ci:bookworm, --test-custom-db, Debian 12 production install with custom db name and user, bookworm) (push) Has been cancelled
Zulip production suite / ${{ matrix.name }} (zulip/ci:jammy, , Ubuntu 22.04 production install and PostgreSQL upgrade with pgroonga, jammy) (push) Has been cancelled
'process_downgrade' is used inside an outer db transaction
created in 'remote_server_post_analytics'.
`transaction.atomic()` block in 'process_downgrade' resulted in
savepoint creation.
This commit adds `savepoint=False` to avoid that.
This commit adds `durable=True` to the outermost db transactions
created in the following:
* confirm_email_change
* handle_upload_pre_finish_hook
* deliver_scheduled_emails
* restore_data_from_archive
* do_change_realm_subdomain
* do_create_realm
* do_deactivate_realm
* do_reactivate_realm
* do_delete_user
* do_delete_user_preserving_messages
* create_stripe_customer
* process_initial_upgrade
* do_update_plan
* request_sponsorship
* upload_message_attachment
* register_remote_server
* do_soft_deactivate_users
* maybe_send_batched_emails
It helps to avoid creating unintended savepoints in the future.
This is as a part of our plan to explicitly mark all the
transaction.atomic calls with either 'savepoint=False' or
'durable=True' as required.
* 'savepoint=True' is used in special cases.
The build_support_url is a more generic function that's used in
the BillingSession framework and will generate the same URL for
these Zulip Cloud support requests.
