* feature_flags:
Put CDRs behind a feature flag
Store feature flags on user for limiting commands, etc
Added a New Command to Display CDRs to Customers
d1dc3e7
Store feature flags on user for limiting commands, etc
Stephen Paul Weber
created
82ac670
Added a New Command to Display CDRs to Customers
Click to expand commit body
Created cdr_repo and now call it from a new command in the Bot, then filter the response through a form to display for the customer.
Refactored some aspects of lib/cdr.rb.
root21
created
c3579cc
Only try to catch up possible renewals if expired less than 3 months
Stephen Paul Weber
created
3cc228e
Changed 'Invite' to 'Referral' where it displays ot the end user.
root21
created
5bdeea5
Reserve TN with bandwith after selection and pass reservation id when ordering
An admin can now add a transaction to an account without having to log
into the DB.
A few notes:
- The transaction ID allows a "%" in it which gets substituted with a
unique value. This is so if you've got a transaction value already,
like an Interac Transfer or something, you can just put it here.
But if I'm making something up like "cash" I don't have to mash the
keyboard just to get a good ID. I can just use "cash_%" and be content
that I'll get a good value
- The notes have a few prefilled values, which is just there for
convenience and consistency.
They're an open list, though, for manual things. Except on clients
that don't support open lists...
- There's an option to notify the user. I haven't built that in this
commit and will come later. This is so that under normal operation we
don't have to message from support and tell them "hey, we've got your
money", and even better we don't have to tell them "hey, we've got
your money, you may want to go talk to the bot to activate".
But if support is already talking to them, we can disable it and tell
them things in a more organic way.
Like I said, I haven't built that in this commit, though.
So, this is a start, at least.
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.