receipts as member of team shouldn't be anon

[chadwhitacre]

On the history page we should show when you receive money from a team (reticketed from #1118).

[ceboudreaux]

$.25 from Someone should say Team-Name instead

[chadwhitacre]

😊

[chadwhitacre]

+1 from @pjz in IRC.

[seanlinsley]

@whit537 mind if I take this on?

Browsing through the codebase, it seems like this code could be changed to:

{% if user.ADMIN and (participant.username != user.username or 'override' in qs) or participant.show_as_team(user) %}
<td class="notes">from <a href="/{{ event['tipper'] }}/history/">{{ event['tipper'] }}</a></td>
{% else %}
<td class="notes">from someone</td>
{% end %}

Could you explain this bit of code?

    def show_as_team(self, user):
        """Return a boolean, whether to show this participant as a team.
        """
        if not self.IS_PLURAL:
            return False
        if user.ADMIN:
            return True
        if not self.get_members():
            if self != user:
                return False
        return True

Specifically, the last condition. What does self != user mean in this context?

[cakey]

I think some documentation on the schema of payday/transfers/exchanges would make this type of issue (especially generating tests) easier.

[zbynekwinkler]

Do we need to JOIN the participants table to the transfers on transfers.tipper == participants.usename and decide based on participants.number?

BTW: I have no idea what either of the ifs does (the template or the code).

[pjz]

I got re-annoyed at this and wrote code using @zwn 's suggested method... but is a simple test of number!='singular' enough? or do we need to also make sure that the user is a member of the non-singular tipper ?

[seanlinsley]

Perusing the blog post, I started watching one of the videos, where @pjz was frustrated that no one responded to this particular ticket. Honestly, so was I. @whit537 I understand that you're constantly being pulled in many different directions, but when questions are never answered, our volunteer efforts stall. If no one cares to answer, what's the point?

At 1:02:XX we discussed the idea that it's that person's responsibility to ping specific people if they need input or assistence. Quoting @whit537 out of context:

If you don't ping somebody, it's your fault.

---

Either way, we should really have a bi-weekly stand-up meeting if we can find a good time for most people. I think having human contact will help a lot.

[chadwhitacre]

@seanlinsley I'm fine with scheduling a regular Hangout. Let's move this conversation over to #1943 ...

[pjz]

@whit537 , @zwn is a simple test of number!='singular' enough? or do we need to also make sure that the user is a member of the non-singular tipper ?

[zbynekwinkler]

We are showing this in the history view of the profile. What am I (as the user) expecting to see?

• When I am a member of a team and set my own take, I am entitled to see the transfer resulting from that.
• I think I should see that transfer in the history view even when I am not a member of that team anymore.
• Actually, I think I should see the transfer even it the team is not a team anymore.

So what would be the best technical solution? I think that marking somehow the transfer is the only way (in the end). Checking if the giver is a team right now is good compromise. The only strange thing is that if the giver was singular and was tipping me in the past, switching to a team would mean all the past tips would be revealed to me.

[seanlinsley]

The only strange thing is that if the giver was singular and was tipping me in the past, switching to a team would mean all the past tips would be revealed to me.

I hadn't considered that. Maybe we should store the singular/plural information on the tip itself.

[zbynekwinkler]

Maybe we should store the singular/plural information on the tip itself.

I think it needs to be on the transfer not on the tip (actually it is not a tip, it is a different table).

[seanlinsley]

That's what I meant -- I'm not that familiar with the database 😅

[duckinator]

+1