~singpolyma/sgx-jmp

ref: 1b9bf2959540f16f493665453383978f6497c79a sgx-jmp/lib/customer.rb -rw-r--r-- 2.3 KiB
On low balance, top-up or notify

On start up, check for users with low balance and NOTIFY about them.  LISTEN for
such notifications and process by either sending a low-balance warning message
or else attempting an auto-top-up as configured.

Using NOTIFY/LISTEN because then we can NOTIFY after any INSERT that leaves the
balance too low (using a trigger).  Doing the sync on start-up in case we missed
a NOTIFY during any downtime.  Using the Redis lock to prevent spamming a
low-balance user in case of many restarts or if they have many small
transactions happen in one day.
Ask electrum to notify on new BTC addresses

Otherwise we won't know when someone has paid...
Factor out CustomerRepo

Using the Repository pattern to encapsulate the fetch and create operations on
the persistence layer for a domain object.  These were not really factories in
the classic sense, but rather "fetch from persisitence layer" methods, and so
they now have a home.
Merge branch 'btc_spop'

* btc_spop:
  Get new Bitcoin address from Redis set
Get new Bitcoin address from Redis set

This set is populated by a cron job to have only known-good available addresses
in it.
Set catapult_fwd_timeout on our backend-facing JID

Not on our inbound-facing JID.  This is why we shouldn't be mucking in the SGX's
Redis at all...
Notify admin if a user goes over 500 messages in 30 days

Notify only once per day (using expiring redis key).
Can notify MUC or user, always sends directed presence first so it will join MUC
if not joined.
Ignore all messages direct to the component, mostly to throw out live messages
from MUC if we join that to notify.
Handle invalid customer id

An invalid customer id is an error from braintree, so handle the error and
return an empty list of payment methods.
Add btc_addresses to Customer

And use that in registration instead of implementing it inline
Merge branch 'create-reset-sip-account'

* create-reset-sip-account:
  Create or reset SIP account
  Factor out Catapult connection
Create or reset SIP account

New command to create or reset SIP account.  Always try create first because
it's faster and more common, fall back to search the list for our account if
that fails due to conflict.  Password is always randomly generated from the
mnemonicode word list.
Usage command

Customer has a CustomerUsage which can fetch data to build a UsageReport
which returns a jabber:x:data form "table" as per spec for per-day in
the last month.

Minutes come from cdr table in postgresql.
Messages come from redis.
Merge branch 'pass-messages'

* pass-messages:
  Pass messages to and from the SGX
Pass messages to and from the SGX

Rewriting the from/to as appropriate.
ergonomics for testing credit card
Merge branch 'create_customer_id'

* create_customer_id:
  Create customer_id if it does not exist before we start registration
  Break out CustomerPlan
  Inject BackendSgx per customer
Create customer_id if it does not exist before we start registration
Break out CustomerPlan

We had Plan and Customer but the relationship between the two lived
entirely in Customer, which was growing quite large. Break that
relationship out into its own concept and give it a name.
Inject BackendSgx per customer

Instead of being a singleton that represents the entire relationship
with the backend, the object is now per-customer (since any meaningful
method requires a customer anyway for the from JID at least) and can be
delegated to directly from Customer.
Merge branch 'invites'

* invites:
  Block repeated invite code tries by customer id
  Allow user to activate using invite code
Next