search

webrecorder / browsertrix

Browsertrix is the hosted, high-fidelity, browser-based crawling service from Webrecorder designed to make web archiving easier and more accessible for all!
https://browsertrix.com
GNU Affero General Public License v3.0
145 stars 29 forks source link

[Feature]: Update org banners to show billing status #1876

Open SuaYoo opened 3 weeks ago

SuaYoo commented 3 weeks ago

Backend changes

Frontend changes

Details

A single banner should be shown depending on priority:

  1. Active org, cancellation date set, and account will be deleted on that date Call to action: Download data or resubscribe
  2. Active org, cancellation date set, and account will become read only on that date CTA: Resubscribe
  3. Read-only org, subscription paused due to payment failure CTA: update payment method
  4. Read-only org, subscription canceled (i.e. readOnlyOnCancel was true) CTA: Contact support/instance admin
  5. Read-only org, other reason (i say display generic reason so that we don't have to worry about writing reasons that are customer-facing, and not translatable) CTA: Contact support/instance admin
  6. Active org, over storage quota CTA: Contact sales/instance admin
  7. Active org, over execution minutes CTA: Contact sales/instance admin
tw4l commented 3 weeks ago

Backend work is already done for this in https://github.com/webrecorder/browsertrix/pull/1871 (OrgOut will return the paymentSuspended field, which will be either a boolean or None). We'll want to display the banner when the value is true.

After talking with Ilya, we're going to modify this so there's just an Organization.readOnly bool and a separate field Cashew can set with the reason, which we can display in the banner. This will get tricky later with localization but is a better compromise for now.

emma-sg commented 3 weeks ago

Maybe one solution to the localization issue would be to have a set of preset string that cause the frontend to display a localized message if it matches its key? It's not ideal in terms of separation between Browsertrix and Cashew, but it'd allow us to make use of our existing localization setup

tw4l commented 3 weeks ago

Maybe one solution to the localization issue would be to have a set of preset string that cause the frontend to display a localized message if it matches its key? It's not ideal in terms of separation between Browsertrix and Cashew, but it'd allow us to make use of our existing localization setup

Yeah that could work for now! And the backend is flexible enough to allow any reason, so if there's not a match in the frontend for a string we can just display it as-is as a fallback?

emma-sg commented 3 weeks ago

Yeah, works for me!