Project history page

[kaguillera]

This is the stub so far...so it is nowhere ready for review

[kaguillera]

According the way that fake_data.py works a payment_instruction is made for each participant for each team except for the team owned by that participant.
Thus if there are five teams and five participant each team should have four payment_instructions. Also it should follow that each payday executes these payments (for simplicity all are funded for now) then each payday should produce four payments per team one for each payment_instruction.

Just realized this is limited by ntips.
The question is can I work on the ticket even if the fake_data is messed up. If not how exactly do I fix fake data to give move realistic data and should I?

[kaguillera]

Ok I think that I will have to go down the 🐇 ⚫ and rework fake_data.py some more to get realistic data so that I can rap my head around this ticket. So this blocked again 😦

[kaguillera]

Initial look of the history page. Give me a little feedback before please. Ignore the data. Since before I properly put this PR for review I have to fix fake_data.py again in order to show realistic data and thus do proper testing of the page.

[mattbk]

Is "Received From" breaking anonymity here?

[kaguillera]

I was thinking that just did not have any idea what would be appropriate
hence the post to see if anyone had suggestions. Over the next few days I
will show other possible ways to present the data. Hopefully

On Oct 4, 2016 10:19 AM, "mattbk" [email protected] wrote:

Is "Received From" breaking anonymity here?

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
#4128 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ABNTSW0tdYgdtXiELGyiVXl5AABnZ0joks5qwmB0gaJpZM4KEFSz
.

[kaguillera]

Once #4150 is merged I will be able to finish this and put this for review

[kaguillera]

Please review this. I still have to do the export link that would produce the data for export via csv or excel but I think that this can be merged and the export aspect can be done in another PR. Oh that is once it passes in travis.

[kaguillera]

Oh and @whit537 I think that I got the same 150+ commit issue due to programming on the bus. I forced the push so that it would not ruin the history of the logs but I really need to find the root of this problem because I think that it will eventually come back to bite me.

[kaguillera]

Burr????

Any ideas???
I did not touch that 🙀

[chadwhitacre]

Sorry, @kaguillera. :-(

Working on the build in #4173 ...

[kaguillera]

No Problem...I don't think there is any need to rush this.

[kaguillera]

Ready for review again. Rebased (at least I think so)

[chadwhitacre]

Rebased, was 118d18b.

[chadwhitacre]

@kaguillera I'm seeing trailing whitespace. Can you configure your editor to remove that when saving?

[chadwhitacre]

This needs to be updated in light of https://gratipay.news/from-teams-to-projects-45c46718507b.

[kaguillera]

Will do

[kaguillera]

Ready for review and merging @mattbk @whit537 @nobodxbodon et. al

[nobodxbodon]

I'd be glad to merge as soon as I see a screenshot that shows a demo page (or first thing on Monday without a screenshot), even if I can't fully review it before that. I don't think it's worthwhile to postpone this even more, given the fact that this is a standalone feature and shouldn't impact existing critical features.

[rohitpaulk]

Looks like this can be removed?

[rohitpaulk]

Might be a good idea to be clear on what format we're expecting arguments in: Is team supposed to be a Team object, or just the team slug? (The latter is the correct answer 🥇 )

I'd suggest using a docstring to describe what the arguments should be, and try passing Team objects around as far as possible.

[kaguillera]

ok will do.

[rohitpaulk]

Since we're using COALESCE, I don't think received will ever be None. Will it?

[kaguillera]

True.

[rohitpaulk]

Same as https://github.com/gratipay/gratipay.com/pull/4128/files#r106806673..

[rohitpaulk]

I don't think we should keep year as an optional here, it already defaults to current_year in the template ( year = int(request.qs.get('year', current_year)) ).

Not that this is wrong, just that it is one more thing to maintain :)

[kaguillera]

Fair enough.

[rohitpaulk]

This looks like a use case for JOIN query.

ie. Instead of

SELECT payments.*, paydays.ts_start
FROM payments, paydays
WHERE payments.payday = paydays.id

use a single JOIN:

SELECT payments.*, paydays.ts_start
FROM payments JOIN paydays ON payments.payday = paydays.id

I find that easier to read (the intent of having multiple tables + their relationship is clear), and from what I've read - databases can do more intelligent optimizations with JOINs compared to multiple SELECTs.

[kaguillera]

Will try.

[rohitpaulk]

I'd suggest naming ts_start as payday_start so that it is clear that it is the start of the payday and not the payment.

[kaguillera]

ok

[rohitpaulk]

I think this can be simplified using itertools.groupby, it does exactly what we're doing here.

Here's what I think this will look like with using groupby:

Before:

events = []
payday_id = payments[0]['payday']
payday_date = payments[0]['ts_start']
payday_events = []

if not payments:
    return payments

#return payments

for payment in payments:
    if payment['payday'] != payday_id:
        events.append (dict(id=payday_id, date=payment['ts_start'], events=payday_events))
        payday_id = payment['payday']
        payday_date = payment['ts_start']
        payday_events = []

    payday_events.append(payment)

events.append (dict(id=payday_id, date=payday_date, events=payday_events))

After:

events = []

grouped_payments = groupby(payments, lambda x: x['payday_id'])
for payday_id, payments in grouped_payments:
	events.append (dict(id=payday_id, date=payments[0]['payday_start'], events=payday_events))

[kaguillera]

the entire day I have been trying to unpack that structure that you suggested @rohitpaulk and it is only giving me the last event i.e. the payout to the owner, every time I try to iterate over the events

[kaguillera]

The following code (this is just an attempt at understanding the structure of the resulting object) should in theory produce a list with the payday_id, payday_date and list out all the transactions for that payday (unformatted)

{% for payday in events %}
    {% set id = payday['id'] %}
    {% set paydate = payday['date'] %}
    {% set pay_events = payday['events'] %}
    {% print id %}
    <br/>
    {% print paydate %}
    <br/>
    {% for each in pay_events %}
        {% print each %}
    {% endfor %}
    <br/>
    <br/>

{% endfor %}

But it does not it produces the following

Any suggestions???
Am I doing something wrong that I can't see.

[rohitpaulk]

Ah - I'll try to take a look at this tonight

[kaguillera]

Going to give this one another try...

[rohitpaulk]

I think this check would be clearer if we explicitly checked for if year > current_year, rather than relying on the fact that if x > y, range(y, x, -1) would not contain x

[kaguillera]

Idea here was to ensure that a person will not put a year in the URL and that year could be greater than the current year or less than the year the team/project 'ctime`

[rohitpaulk]

Should the taker be anonymous here?

[mattbk]

Changed in d54faa7.

[rohitpaulk]

Had a quick glance through, left comments

[mattbk]

!m @rohitpaulk

[mattbk]

Current status:

[mattbk]

Oops.

ETA: Travis timed out.

[chadwhitacre]

Travis timeout is likely #4359.

[kaguillera]

Ready for final review once again.

[mattbk]

LGTM

[mattbk]

puts his finger on the button...