The reason for doing this is so a library can put in money with one
check, then use it up gradually. (we get to pocket the fees that would
go to stripe) One change here- in b2u there is an extra click to get to
download page, even if no gift credit is involved - this way the user
knows what and how he's bee charged
There were four places in the code that triggered the
recharge_failed_transactions signal and only one of them mattered. I
think this layout makes the code much easier to understand.
* [ ]https://github.com/Gluejar/regluit/pull/176/files#r4221450 "It also seems odd to be using signals to talk only within the same module. This seems to me to be a misuse of signals, and makes for code that is harder to read" -- I need to decide whether I agree w/ Eric.
* [ ]https://github.com/Gluejar/regluit/pull/176/files#r4366503 long exchange "making it readonly would be overkill (java-ish) but the current code is not clear. Your save signal handler has to figure out whether a state transition has occurred and then act accordingly, which seems like a lot of hoops to jump though. better to put all the transition work in one place. For example, shouldn't it be the deactivate method that sets the status to deactivated?
For example, the methods on campaign do a reasonable job of handling all the status transitions." What I should: mimic structure of 4fc449dad5/core/models.py (L322) -> time to write up how Campaign works
* [ ]https://github.com/Gluejar/regluit/pull/176/files#r4214827 "could also mean the Account has been deleted. don't you really want instance.pk=None?"
* [ ]https://github.com/Gluejar/regluit/pull/176/files#r4221509 "since, these actions are being done in batch mode, the emit notifications would work a lot better if they were emitted after the batch of notifications is created."
eric
Raymond Yee
Andromeda Yelton