-
Notifications
You must be signed in to change notification settings - Fork 308
clean up Twitter integration #406
Comments
This is about the interaction of participants with social_network_users. |
Participants can be claimed or unclaimed. Unclaimed participants are 1:1 with a social_network_user. Claimed participants are 1:N with social_network_users. |
I think it might be time to implement a bit of an object model for participants. I started this at one point but then backed it out and I can't remember why. :-( Currently we interact with participants mostly through functions in gittip/init.py. I'm considering defining Participant and SocialNetworkAccount classes. All of the participant = Participant('whit537')
tip = participant.get_tip_to('dowski')
# etc.
github_account = GitHubAccount('whit537')
twitter_account = TwitterAccount('whit537')
participant.connect_account(github_account)
participant.connect_account(twitter_account) |
I need to make sure b340cf8 works for authenticated users (ideally with some more tests in test_pages.py) and then I'll release this so far. |
Okay, work so far is deployed as 5.4.28. |
Next steps:
|
I am renaming this because I want the Python library nomenclature to harmonize with the database, and I don't want to call the Python submodule social_network_users (it was called networks before). Now they're both called elsewhere. Secondly, I want to broaden the category to include things that might not necessarily be social networks (is Vimeo a social network?). Platform is more generic. This commit also adds some more page smoke tests. There's a lot more to test. :(
How will participant absorption affect nparticipants during payday? |
Deployed work to date as 5.4.33. |
I modified the test fixture to setup data in the elsewhere column, but it turns out we depend on lowercase for platform names, and the test fixutre didn't use lowercase.
I believe these tests hit the database in a way they didn't before, due to the way we're filling out the elsewhere table now(?). Anyway, they weren't wrapped in a db testing context manager, so there was bleed-through. Maybe they were always bleeding, I dunno.
When I added the additional constraints to the elsewhere table, I broke the upsert method. In fixing it I was able to greatly simplify it.
Deployed as 5.5.3. |
This avoids creating and then deleting participants.
I'm refactoring the login machinery. |
This centralizes all upsert calls to AccountElsewhere.__init__. That means when you instantiate that object it updates the database.
We were only getting gifts *to* people with a valid credit card. Oops!
Punchlist for UI:
|
General punchlist:
|
Deployed as 5.5.7. |
The two main tickets so far for this are #289 and #313. I'm starting a new ticket here so that I can talk to myself without interrupting all the watchers on those tickets. :-)
The text was updated successfully, but these errors were encountered: