* Sync owner email to Stripe when changed
When an account owner changes their email address, update the
corresponding Stripe customer record via a background job.
Also handles ownership transfers: when a user becomes the account
owner, their email is synced to Stripe.
Responsibility chain:
- User::NotifiesAccountOfEmailChange triggers on owner identity change
or when a user becomes owner
- Account::Billing#owner_email_changed enqueues sync job
- Account::SyncStripeCustomerEmailJob performs the update with
polynomial backoff retries
- Account::Subscription#sync_customer_email_to_stripe calls Stripe API
* Address PR feedback: error handling and test coverage
- Handle Stripe::InvalidRequestError in sync_customer_email_to_stripe
(mirrors cancel method behavior for deleted customers)
- Add test for deactivated owner (owner with nil identity)
- Add test for deleted Stripe customer scenario
* Add self-service account deletion
* Disable access to cancelled accounts & implement Stripe interactions
* Add tests
* Fix failing tests
* Remove cancelled accounts from lists
* Fix incorrect redirect
* Use _path instead of _url for consistency
* Don't track how far the inicieration job got
We still want the step tracking so that the job can be interrupted. But, since the scope is idempotent, we don't need to track how far it got.
* Specify the exact time when the data will be deleted
* Fix crash due to unadvancable cursor
* Rename up_for_incineration to due_for_incineration
* Regenrate the schema
* Fix incorrect path check
* Migrate the SQLite schema
* Only show the cancel button on cancellable accounts
* Check that a subscirption method exists before calling it
* Ignore job failures due to missing records when an account gets deleted
* Skip sending notifications on cancelled accounts
* Use collbacks to integrate
* Add a blank line between queue_as and discard_on
* Break checks into methods
* Inline methods
* Rename Account::IncinerateJob
* Run migrations
* Migrate SQLite
Before, we were relying on just changing the cards_count in account, but this
could create problems where the system to calculate the next card number fails due
to the unique constraint.
To keep as much of this as we can in the `fizzy-saas` gem, this PR
opts to store console/audits models in a separate database, and so:
- the gem contains the migrations and the database config
- the app contains a separate schema file distinctly for SaaS concerns
- Rails' current behavior prevents us from easily keeping this file in the gem
Also note that the stock `audits1984` schema is updated to reference
the auditor via a UUID foreign key.
Finally, in order for the database schema file to be located in the
gem directory (and not the application directory), it's necessary to
monkeypatch `AR::DatabaseTasks.schema_dump_path` to support absolute
paths. This functionality has been proposed upstream in
https://github.com/rails/rails/pull/56290 but is awaiting a decision
from the core team.
ref: https://app.fizzy.do/5986089/cards/2469
ref: #17
Jeremy Daer