Last modified: 2013-12-15 12:17:48 UTC
The trigger used to populate public_reporting should write anonymized data points to a separate database. The extension's dependency on the Civi db is unnecessary, and dangerous at any speed. Also a bug on http://svn.wikimedia.org/viewvc/wikimedia/trunk/fundraising-civicrm/sites/all/modules/public_reporting
half a patch: http://www.mediawiki.org/wiki/Special:Code/Wikimedia/2284
https://gerrit.wikimedia.org/r/34487
The real work here is in deployment. One potential sequence of operations: * Create the new public_reporting database and table. * Pause the queue consumer. * Copy existing public_reporting data from the civi db to new db. * In drupal, admin/settings/public_reporting/settings, set the new database name. * Create new triggers. * Slow-start the queue consumer. * Reconfigure Foundation wiki ContributionReporting to point to the new db. * PopulateFundraiserStatistics
(In reply to comment #2) > https://gerrit.wikimedia.org/r/34487 4-line patch for extensions/ContributionReporting needs reviewers - Adam, anybody in mind who could be added as a reviewer in Gerrit?
Change 34487 merged by Mwalker: (bug 42285) make explicit that the public_reporting table is not in the civi db. https://gerrit.wikimedia.org/r/34487
OK; I've committed the patch considering it was only modifying comments. The bigger issue here is that as of this morning; have no method to continue supporting ContributionTracking via writing to public databases. This came as a result of us finally moving all the fundraising databases into the fundraising rack. Because of that; and because we have a source of data available through frdata.wikimedia.org (we just don't have a dashboard for it that works) I'm going to mark this as WONTFIX.
[Moving from "CiviCRM/General" to "Wikimedia/CiviCRM; see bug 57738]
