* prev:
Allow prev from mail-in registration
Allow prev from invite code
Allow prev from credit card form
Make sure OOB comes first in payload
Allow prev from Bitcoin registration
Allow prev action on TelSelections search results
* no-15-spin:
Auto top up enough to get to auto_top_up_amount
Remove Customer knowledge of all presenter objects
Stephen Paul Weber
created
6acb4d2
Auto top up enough to get to auto_top_up_amount
Click to expand commit body
If auto top up amount would not get us to $5 (because of very negative balance),
we don't want to loop multiple auto top ups, so instead just do one larger one
to get to auto_top_up_amount
Stephen Paul Weber
created
0323f43
Remove Customer knowledge of all presenter objects
* multi-account-billing:
Use billing customer for LowBalance notification
Get settled amount from billing customer for TrustLevelRepo
Use the multi account billing schema
Stephen Paul Weber
created
5ad2c9e
Use billing customer for LowBalance notification
Stephen Paul Weber
created
8b80a1f
Get settled amount from billing customer for TrustLevelRepo
Having a second response here just to show the result, and then have to
skip by it to get back to the menu is dumb.
So instead we just added a thing here so we can tag some info to show up
on the next form, and then go to it.
Much smoother, but it does depend on a change in the adhoc bot which
previously didn't show notes when there was also a form.
Here we have a form for the extra information we need. They say they
want to set the trust level, we ask which one they'd like, and then we
make the command that does that.
This involves adding a new method to the TrustLevel to get just the
manual level, so I can tell the difference between being set to Customer
manually (in the form) or being automatically determined to be Customer
(which means the form should be set to automatic).
I also obviously need the method to set a new trust level too.
This is a nice simple first one.
I set the declines to 0, and on Undo I set it back to what it was
before.
There's no extra form or information, it just does the thing.
It's a little weird to start with Undo when there's nothing to Undo yet,
but it's laying the groundwork for what's to come.
This gives me a harness I can use here that gets the action, performs
it, gets the result of that performed action, and then persists that to
the log and reports success or failure.
And the first such action I have just grabs the most recent item and
undoes it.
This class gets pretty tight later, so I have to move these out to make
room in the class for the other commands.
This Simple class is a bit weird on its own here, but it makes a bit
more sense later when compared to another class.
This allows me to enqueue a description of a change to a stream and then
run it. And then later find / list them and undo any of them.
The goal here is to make these safe to run and safe to reverse so the
user can just run things with confidence knowing that undo's always got
their back.
This allows me to avoid confirmation boxes on everything and careful
scrutinizing of each command before it's run just in case...
In preparation for another command I'd like to make I've first got to
make a place where Invites live.
There's probably other parts of the code that interact with Invites that
I've missed, but this is a good start at least.