This is a refactor that involves pulling the Credit Card stuff (meaning
braintree) out of the Transaction stuff. This makes Transaction a more
generic implementation of our Transaction table.
This commit should maintain the status quo, though. The places that used
to call Transaction.sale now call CreditCardSale.create, and that got a
little easier because we now do the `.insert` inside the create, because
previously all the callsites just got the transaction out and then
inserted anyway.
So they got a little bit simpler, but the main value of this is that now
we can insert other kinds of transactions and not just credit card
transactions!
Instead of just having a list of targets we don't charge for and that don't
count towards limits, instead a list of targets where we know their JID and send
them messages directly, bypassing even the SGX.
In practise we will use this for support. This means support messages will not
traverse billing code, or the sgx, and will work even if the sgx is down or the
customer has no configuration there at all (or a broken configuration there)
including if the customer has no phone number.
Support will get messages from customer_<customerid>@jmp.chat and can reply to
those. Customers will still message the support phone number via @cheogram.com
and see the replies coming from the support number.
Anyone messaging the support phone number from outside our system (ie from
carrier SMS) will still show up as phonenumber@cheogram.com to support, since
that won't traverse this path. If someone messages support without a cheogram
route that will still come as whispers since those don't traverse sgx-jmp at all
right now.
In the unlikely case that someone has a cheogram route set, but no customer id
at all, then these will come from <escaped jid>@jmp.chat and currently cannot be
replied to, but at least support will see that something is up and be able to
take action.
Allow choosing Done, Add Bitcoin, XMR, or ETH with the last two being SimpleSwap
swap addresses (and thus only one-time use, for safety, we don't know how long
they keep a record of swaps etc).
Canadian ports need this extra info to port them in. Up until now I've
been messaging people manually to ask for it, but that adds a delay to
the porting process since I can't move forwards until they've told me,
and it may be hours between when they fill out the form and when I'm
processing it.
So this will just ask for all the data upfront, meaning I can fully
process them right away.
07c3da0
Render useful message when trying to leave voicemail for no customer
Stephen Paul Weber
created
f5ad677
Actually handle outbound attempt from unknown customer
Stephen Paul Weber
created
6ce95ed
Skip asking backend about registration when we know the tel already
Click to expand commit body
This is an optimization. If we are looking up by tel already, then we don't
need to ask the backend sgx if they have a tel or what it is, we know that, so
just use that information directly and save us a call.
* 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