Participants on Gratipay give payments and take payouts.
Represent a Gratipay participant.
Return a new participant with a random username.
Return an existing participant based on id.
Return an existing participant based on username.
Return an existing participant based on session token.
The path part of the URL for this participant on Gratipay.
Database: One UPDATE, one row
session_expiresto the given datetime.
Database: One UPDATE, one row
Get the participant’s statement in the language that best matches the list provided.
Given a username, return an URL path.
Close the participant’s account.
Zero out the participant’s payment_instructions.
Leave all teams by zeroing all takes.
Clear personal information such as statements.
Return an AccountElsewhere instance.
Return a dict of AccountElsewhere instances.
Return the list of (platform, user_id) tuples that the participant can log in with.
Deletes account elsewhere unless the user would not be able to log in anymore.
set_payment_instruction(team, amount, update_self=True, update_team=True, cursor=None)¶
Given a Team instance, and amount as str, return a dict.
We INSERT instead of UPDATE, so that we have history to explore. The COALESCE function returns the first of its arguments that is not NULL. The effect here is to stamp all payment instructions with the timestamp of the first instruction from this ~user to that Team. I believe this is used to determine the order of payments during payday.
The dict returned represents the row inserted in the payment_instructions table.
Given a Team instance, return a dict.
Given a Team instance, return a Decimal.
Return a list and a Decimal.
Returns a tuple: (sum, number) of old-style 1.0 tips.
get_teams(only_approved=False, only_open=False, cursor=None)¶
Return a list of teams this user is an owner or member of.
Given a Team object, return a boolean.
Raise Response or return None.
Usernames are limited to alphanumeric characters, plus ”.,-_:@ ”, and can only be 32 characters long.
Sanity-check that teams and balance have been dealt with.
Given a cursor, use it to archive ourself.
Archiving means changing to a random username so the username they were using is released. We also sign them out.
Given an AccountElsewhere or a tuple (platform_name, user_id), associate an elsewhere account.
Returns None or raises NeedConfirmation.
This method associates an account on another platform (GitHub, Twitter, etc.) with the given Gratipay participant. Every account elsewhere has an associated Gratipay participant account, even if its only a stub participant.
In certain circumstances, we want to present the user with a confirmation before proceeding to transfer the account elsewhere to the new Gratipay account; NeedConfirmation is the signal to request confirmation. If it was the last account elsewhere connected to the old Gratipay account, then we absorb the old Gratipay account into the new one, effectively archiving the old account.
Here’s what absorbing means:
consolidated tips to and fro are set up for the new participant
Amounts are summed, so if alice tips bob $1 and carl $1, and then bob absorbs carl, then alice tips bob $2(!) and carl $0.
And if bob tips alice $1 and carl tips alice $1, and then bob absorbs carl, then bob tips alice $2(!) and carl tips alice $0.
The ctime of each new consolidated tip is the older of the two tips that are being consolidated.
If alice tips bob $1, and alice absorbs bob, then alice tips bob $0.
If alice tips bob $1, and bob absorbs alice, then alice tips bob $0.
all tips to and from the other participant are set to zero
the absorbed username is released for reuse
the absorption is recorded in an absorptions table
This is done in one transaction.
NeedConfirmation(a, b, c)¶
Represent the case where we need user confirmation during a merge.
This is used in the workflow for merging one participant into another.