~singpolyma/sgx-jmp

ref: c7ebad17fa39584f92a6d317dc2f465990fe088d sgx-jmp/lib/customer.rb -rw-r--r-- 2.8 KiB
Helper to fetch customer's vcard-temp
The sugar version prevents the promise from being returned
Customer Info

This should allow us, the admins, to query information about a customer
without having to dive in and run a couple redis queries and some
database queries before getting the full picture of who we're talking
to.

It also allows the users to request some data about themselves. Balance and
phone number are already visible in other places, but their expiry is currently
not, and people have been asking about it.
Remove BigDecimal.new

It turns out in newer versions of Ruby this isn't cool anymore.
The new way is BigDecimal(value), which is dumb, but whatever...
Merge branch 'invite-codes'

* invite-codes:
  Command to list unused invite codes
Command to list unused invite codes

Instructions also provide details about how the program works.
Customer always has a JID
Merge branch 'low-balance-auto-top-up'

* low-balance-auto-top-up:
  Some people have exactly 5 who don't need to be told
  On low balance, top-up or notify
  ExpiringLock helper
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.
Next