~singpolyma/sgx-jmp

sgx-jmp/lib d---------
Revert "Merge branch 'limit-top-up-freq'"

This reverts commit 7a28753d7df5d7d6f5f890d302634b1bdbd25f73, reversing
changes made to e4ec9b8eb368ed0997887ebd99f8c79982640d20.
Merge branch 'limit-top-up-freq'

* limit-top-up-freq:
  Only allow one credit card transaction per customer per day
Move between accounts requires a sip peer id
Update iris patch for new gem version
EmptyRepo can wrap another to allow mutation
Only allow one credit card transaction per customer per day
Merge branch 'cancel-account'

* cancel-account:
  Admin command to cancel customer
  Move Customer factory/extractor to Customer
Admin command to cancel customer

Notify customer
Deregister from SGX
Deregister from Cheogram
Disconnect from Bandwidth
	If on special list, move intead of disconnect
Move Customer factory/extractor to Customer

The repo's job is to get the data, constructing the object can be a factory's job.
Merge branch 'more-admin-info'

* more-admin-info:
  Test Admin Info with Numbers
  Refetch Customer on Repeated Customer Info Calls
  Trust Level in Customer Info
  Show Callability State in Customer Info
  PromiseHash
  No Settled Transactions is 0, not Null
Test Admin Info with Numbers

My current two AdminInfo tests have unregistered customers because it's
easier, but it means that some parts of the logic don't get tested.

This one digs a bit deeper to test this part of the forms, but it
requires injecting a repo
Refetch Customer on Repeated Customer Info Calls

This means if I fetch a user, make a change (add a transaction, set
their trust level, etc), I can re-run info from the menu to get the same
user with up-to-date info, so you can see the thing I just did reflected
back to me.
Trust Level in Customer Info

We have this thing, so we should probably be able to see it
Show Callability State in Customer Info

This shows relatively easily which class a given user finds themselves
in.

Whether they can't call because they have no balance, or if they have
lots of room, or if they're being asked.

Hopefully this will make it easier to tell at a glance if a calling
issue is due to a few things.
PromiseHash

Here in info I'm doing a lot of this pattern:

    EMPromise.all([one, two three]).then { |one, two, three|
    	new(one: one, two: two, three: three)
    }

Which felt really noisy for what is a pretty logical operation.
So now I can keep the keys and values together and do:

    PromiseHash.all(one: one, two: two, three:three).then(&method(:new))

It's smaller, but more importantly it's more meaningful to me.
It keeps the declaration of the meaning together with the sourcing of
the value.
And because it uses EMPromise.all in the guts it's not a problem if some
of the keys are not promises.
Easy-peasy!
No Settled Transactions is 0, not Null

Unexpectedly this doesn't return either no columns or a column with a
value of 0, but instead a column with no value...
Merge branch 'message-limits'

* message-limits:
  Block outgoing messages when expired
  Contacting support is not billable
  Use TrustLevel to determine daily quota
  Refactor message limits, change to 500/day
Use TrustLevel to determine daily quota
CallAttempt needs customer
JID Switch

This allows a customer to change their JID, but it's a bit raw.
In practice I don't expect anyone to actually run this directly, instead
cheogram covers with with a friendlier and safer version.

This is just the business.
Next