-
Notifications
You must be signed in to change notification settings - Fork 308
Conversation
854f948
to
afdfd75
Compare
Made some progress on this on the bus this morning. Rebased and pushed. |
afdfd75
to
fc87663
Compare
Alright, getting back to this. I'm looking at |
e4cd2f6
to
b3c050e
Compare
This is ready for review, @Nashe @aandis @rohitpaulk! I split off a new PR for MassPay (#4111). |
Found a bug while working on #4111. Withdrawing |
06f3998
to
66d1023
Compare
Okay, fixed. Ready for review again! :-) |
I don't have a lot of things to say since I'm not familiar with this part of the code—but nothing shocked me. Waiting for a second approval? |
Thanks @Nashe. @rohitpaulk Would you be able to spare any cycles this week to look this over? This and #4111 are the last two major PRs needed to land payouts for Team Gratipay! |
self.enterprise.set_take_for(self.picard, D('0.01'), self.picard) | ||
with pytest.raises(NotAllowed): | ||
self.enterprise.set_take_for(self.picard, 50, self.picard) | ||
return # XXX allow owners to join teams! |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hmm, what is happening here? What is the limitation that we're facing in allowing owners to join teams? And if we are going to do it in the future, do we have a vague idea of how we'd do it? My main concern here is whether we're making a decision that will make it harder to re-introduce this functionality in the future. (we'll build more stuff that assumes this is not going to happen, and then that'll be harder to reverse)
I guess the fundamental issue here is that we don't allow a payment sink to be tied to a team (we drain funds to the owner's bank account) - however - We could still process takes to the owner, right? And in the future when we do allow linking bank accounts to teams - the only piece that will change is process_remainders
.
I think this is also nice in terms of the payroll functionality - we want an owner to be able to set 'their' take - and have the rest go to the team. It won't make a different right now in terms of where the money goes - but teams could use that data to decide how to split money internally. For example, if @whit537 was the owner of Gratipay - he could set a take and have the rest flow to the team. And once a month, he could look at the takes
history and decide how much to move to his personal account and how much to keep in the team's operations account.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I know @kaguillera and I talked about this, and I thought I recorded somewhere that we thought it was okay to allow owners to join teams. Looking for that ...
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Found it!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ready for review in 3ac7fee.
FIrst pass done, only real concern is #4102 (comment) - the rest are just code-style/tests stuff that I'll clear myself in a while |
@rohitpaulk Awesome! I've updated the todo and will look into these right after lunch ... 🍗 |
I like how all my comments have magically appeared as to-do items on the description of this ticket 😉 |
Let's communicate if/what we're working on to avoid stepping on each others' toes. I'm working on putting food into my head. :) |
:) I'm working on " fix order of calls (and test!)" right now |
Done with that, now looking at "refactor process_distribution for clarity" |
Should we rename it back to |
self.payday.update_balances(cursor) | ||
|
||
assert P('alice').balance == D('100') | ||
assert P('picard').balance == D('400') # Owner receives whatever is left |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this test expected to fail without 84f4b31? That was my expectation, but when I manually revert that commit locally this test still passes.
Also: Let's find the right place for this in the test suite. Where it is now it should have a name like test_pt_
for both conceptual grouping and easy filtering with py.test -k test_pt_
. Maybe it would work better up in the TestPayday
class?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this test expected to fail without 84f4b31? That was my expectation, but when I manually revert that commit locally this test still passes.
I see how this is confusing - the first test is only testing process_remainder
in isolation, and I think it'd be clearer if we just remove process_takes
from there.
The order should only matter in the new test that I wrote (that tests the interaction between those two).
Maybe it would work better up in the TestPayday class?
Yep, agreed - on it
Ducking out for gratipay/inside.gratipay.com#792, bbiab ... |
Decided that the extra 'isolated' test wasn't worth it, so merged both into one. Since both |
Now to squash these commits a bit.. |
174e8fc
to
0ed1d31
Compare
Done. |
51af227 is what I could come up with to fix "refactor process_distribution for clarity" Why I think it is better:
|
Off for tonight, will check back tomorrow morning! 😴 |
Back from gratipay/inside.gratipay.com#792, catching up ... |
Looking at this ... |
0b88b4d
to
b71a39f
Compare
b71a39f
to
3ac7fee
Compare
I'm good to merge if you're good with 241bc51 and 3ac7fee, @rohitpaulk. |
🎉 Woo-hoo! 💃 |
⬑ #3994
← #4077 — #4113 →
Remake of #4025.
TODO
include members in MassPay; see→ Refactor test_billing_exchanges #4113get_ready_payout_routes_by_network
process_distribution
for clarity—Bring back takes in payday #4102 (comment) —started in Bring back takes in payday #4102 (comment) —done in 51af227