Fix cached values

[rohitpaulk]

No description provided.

[chadwhitacre]

Ready for review yet, @rohitpaulk? :)

[rohitpaulk]

Not yet, @whit537. I've been busy lately, will get back to this as soon as I can.

[chadwhitacre]

What's left to do? I can spend some time on this ...

[rohitpaulk]

@whit537 -

• Update Participant#update_receiving, and revive related tests.
• Update fake_payday.sql

[rohitpaulk]

^ That's the functionality part. Once that's done, expose giving/receiving in the UI for participants, and only receiving for teams.

[chadwhitacre]

!m @rohitpaulk

Thanks, I'll take a look.

[chadwhitacre]

P.S. In Python, methods are spelled Participant.update_giving, not Participant#update_giving. ;-)

[chadwhitacre]

Rebased on master.

[chadwhitacre]

Hrm ... we're still using set_tip_to extensively in the test suite. It's about time to nix set_tip_to, I think.

[chadwhitacre]

Rebased on master.

[chadwhitacre]

Rebased on master to pick up #3655.

[chadwhitacre]

I don't want to touch tips in absorptions/take_over, because one ~user could take over another and then migrate to a Team: we'd want the tips from both ~users to make their way through to the Team.

[chadwhitacre]

We've standardized our nomenclature. How does that apply here? What are the values we're caching? Do we want both sum and count for each variable? What would that be?

[chadwhitacre]

                sum           count        sharing bit
                ----------------------------------------------
current  ~user  giving        —            anonymous_giving
                receiving     npatrons     anonymous_receiving
                taking        —            anonymous_receiving

         Team   receiving     nsupporters  —
                payroll       nmembers     —       

target   ~user  giving        nrecipients  anonymous_giving
                taking        nteams       anonymous_taking

         Team   receiving     ngivers      —
                distributing  nmembers     —

Look right?

[chadwhitacre]

Are we just giving up on the JSON APIs? 2.0 is a breaking change from 1.0. We simply don't have the same semantics anymore. We don't have a receiving or an npatrons to show for ~users. Right? Does that mean we should 404 all old-fashioned endpoints? Or are we okay with changing the endpoints in subtly non-backwards-compatible ways?

[chadwhitacre]

I don't think we should pretend that npatrons is what I'm calling nteams above: the count of the number of teams a ~user is taking from.

[chadwhitacre]

We shouldn't silently masquerade the value of nteams as the value of npatrons.

[chadwhitacre]

Rebased on master.

[chadwhitacre]

Rebased on master again.

[chadwhitacre]

Tests are passing and we've stared at this for months. I've merged this and will pick up with further rationalizations on a new PR.

!m @rohitpaulk