We should add a field to the contribution_tracking table (write a migration in the ContributionTracking extension) to hold the banner history ID. The ID will be passed through donatewiki when applicable. DonationInterface on paymentswiki will record that ID as part of storing the contribution_tracking row.
|wikimedia/fundraising/crm : master||Add banner_history module to consume BH log id associations|
|mediawiki/extensions/DonationInterface : master||Add banner history log ID processor|
|mediawiki/extensions/CentralNotice : master||bannerHistoryLogger.sendLog: use the promise from logEvent|
|Open||None||T112923 [EPIC] Banner history post launch|
|Resolved||AndyRussG||T112022 Associate banner history ID with contribution_tracking ID|
|Resolved||Ejegg||T118349 Determine what was breaking GlobalCollect in paymentswiki 3730cff20|
Do we need to tie a specific banner history to a specific contribution? The original plan was a standalone table that just got an entry for each banner history that led to a donation. If we want amounts, maybe add another column and fuzz the totals?
Here's a beta cluster banner with a wee script that does this:
It looks like this is the best we can do for browsers that don't support sendBeacon, given current limitations in EventLogging on that count.
Test it out like this:
Here's a patch by @Ejegg to improve EL for this:
Also TODO: make bannerHistoryLogger actually use the EL promise. :)
The sendBeaconlessness workaround works, or at least smoke tested once, on beta labs, with waitLogNoSendBeacon set to 200 ms, on the following platforms:
- IE10 (Win7)
- IE11 (Win7)
- Native Android browser
- Mobile Safari (iPhone 5 emulator)
- Safari 9 (OSX11)
I think we're good to deploy this part!!
It's really close! Things left to do:
- Choose a cron period.
- Set the job time limit to be something like (period - 15 seconds)
- Create a Jenkins job, basing it on one of the other queue consumer jobs.
- Run once to debug, examine the console output and verify that data actually went to the right places.
- Set to run on a schedule.
The DI patch that handles banner history has been deployed, and the Jenkins job to run the Banner History queue consumer is up and running! (Thanks a ton, @Ejegg!!)
Associations of banner history log IDs and contribution tracking IDs appear to be accruing normally in the table in the database. I successfully correlated a record in the contribution_tracking table with a banner history log received via EventLogging!