Page MenuHomePhorge

Implement a changelog to further the debiting of wallet balances
ClosedPublic

Authored by vanmeeuwen on Feb 25 2020, 9:08 AM.
Tags
None
Referenced Files
F11581467: D964.id2392.diff
Thu, Mar 28, 2:28 AM
Unknown Object (File)
Wed, Mar 27, 4:10 PM
Unknown Object (File)
Tue, Mar 19, 6:30 PM
Unknown Object (File)
Mon, Mar 18, 6:35 AM
Unknown Object (File)
Sun, Mar 17, 1:16 PM
Unknown Object (File)
Fri, Mar 15, 2:34 AM
Unknown Object (File)
Mon, Mar 4, 9:22 PM
Unknown Object (File)
Wed, Feb 28, 12:53 PM
Subscribers
Restricted Project

Details

Summary

This differential maintains a changelog entry for every modification to an entitlement, as it happens.

After a period of time (most notably, 13 days, 14 days, 15 days, 1 month, 2 months, etc.), the expected charges can be calculated from that changelog.

There's a number of TODOs left;

  • Pro rata temporis calculation
  • Actual charging of the wallet.
  • Prediction of the next charge (when, what and how much)
  • Collate the 'creating' and 'charging' queries to ->sum() the values of the columns.
  • Evaluate the number of duplicate 'cost' columns
  • subscription period for the sku (i.e. domain registered with us -> yearly)
Test Plan
$ vendor/bin/phpunit tests/Feature/BillingTest.php

Diff Detail

Repository
rK kolab
Branch
dev/billing-without-changelog
Lint
No Lint Coverage
Unit
No Test Coverage
Build Status
Buildable 28321
Build 10105: arc lint + arc unit

Event Timeline

vanmeeuwen created this revision.
  • Implement the pro rata temporis calculation

Testing shows this fails, I'll have to redo with another approach.

  • work
  • Renew the basics for billing
  • Just use the relationship
  • The inverse of the same relationship
  • Do it without the changelogs table
machniak added inline comments.
src/tests/Feature/Jobs/UserVerifyTest.php
25

It fails for me too sometimes. Maybe $user->fresh()->isImapReady() would fix it.

src/tests/Feature/Jobs/UserVerifyTest.php
25

No, it does not make sense.

The test can be written "better", or at least in a way that is supposed to be more reliable.

  • Test userverify with a "guaranteed to be new" user, and a fake queue

Looks good for now.

src/app/Observers/PackageSkuObserver.php
20

You calculated this a few lines above.

src/app/Wallet.php
89

I guess we should use db transactions here. Also, I'm thinking that we may anyway need a changelog table to have easy access to what/when was charged?

vanmeeuwen added inline comments.
src/app/Observers/PackageSkuObserver.php
20

hihi, indeed, because of the superfluous debug ;-)

src/app/Wallet.php
89

This would be in some sort of transactions table, for sure -- I just don't want a future use of cashier (stripe/braintree) to have us need to redo whatever that transactions table is.

vanmeeuwen marked 2 inline comments as done.
  • This was pointless
  • Implement the pro rata temporis calculation
  • work
  • Renew the basics for billing
  • Just use the relationship
  • The inverse of the same relationship
  • Do it without the changelogs table
  • Superfluous log
  • Test userverify with a "guaranteed to be new" user, and a fake queue
  • Remove superfluous debug statement and duplicate calculation

I reviewed it again, I guess it's ready to be merged.

One note, at this project stage we anyway use migrate:refresh often (are we?), so I think that these database changes don't require a new migration file, they could be added to the file that creates the table.

This revision is now accepted and ready to land.Mar 6 2020, 9:52 AM
This revision was automatically updated to reflect the committed changes.