Page MenuHomePhabricator

wikilove_log should be replaced with EventLogging
Open, MediumPublicFeature

Description

WikiLove logs actions to a custom database, for analytics purposes. This was before we had EventLogging infrastructure. Since we now do have EventLogging infrastructure, we should migrate to that and ditch the database.


Version: unspecified
Severity: enhancement

Details

Reference
bz60984

Related Objects

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 22 2014, 3:03 AM
bzimport added a project: WikiLove.
bzimport set Reference to bz60984.
bzimport added a subscriber: Unknown Object (MLST).

From an analytics perspective it's not going to make any difference. The only difference is that logging via EL makes the data private by default (we haven't figured out yet a good way to publicly distribute the subset of EL data that is not privacy sensitive – this may or may not happen in the near future). By switching WikiLove logs to EL we will turn data that historically has been publicly accessible via labsdb or the toolserver into private data.

Given that all WikiLove messages are regular edits, this may not be such a big deal (we might consider a dedicated revision tag if we don't have one).

I already implemented a revision tag ('wikilove') that has been merged :) Point taken about wikilove_log being available on labsdb. Perhaps we could just make that log available via an API query...

Using EL is beneficial because it means we don't have to support a custom database table and analytics setup.

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 12:23 PM
Aklapper removed subscribers: DarTar, wikibugs-l-list.

I'm not sure we need EventLogging given that we have the change tag.

The relevant code is logging this data:

$values = [
			'wll_timestamp' => $dbw->timestamp(),
			'wll_sender' => $user->getId(),
			'wll_sender_editcount' => $user->getEditCount(),
			'wll_sender_registration' => $user->getRegistration(),
			'wll_receiver' => $receiver->getId(),
			'wll_receiver_editcount' => $receiver->getEditCount(),
			'wll_receiver_registration' => $receiver->getRegistration(),
			'wll_type' => $type,
			'wll_subject' => $subject,
			'wll_message' => $message,
			'wll_email' => $email,
		];

Based on the revision + change tag, a data analyst could reconstruct all of this information, with the possible exception of type. That is not documented but looking at the JS code that calls the API, it looks like it should be something like barnstar or makeyourown; not sure if that is important.

So if Product-Analytics is comfortable using the revision table for analysis instead of the wikilove_log table, then this task is just about removing the references to the table and follow up work with DBA to remove the tables in production.