@MNeisler The data to be logged all seems reasonable. I'm assuming that platform will have the same complicated relationship with reality as the existing schemas' usage of it (i.e. "mobile" will mean "MobileFrontend", without any relationship to whether it's running on a mobile device per se).

Adding this to EditAttemptStep seems like a poor fit, as it'd somewhat create a whole new class of session -- one where all the normal editor-initialization doesn't apply and we just log a "edit wasn't even attempted" event.

Should we maybe pursue the new Metrics Platform for this? @phuedx?

Change 820908 had a related patch set uploaded (by DLynch; author: DLynch):

[schemas/event/secondary@master] New schema: editattemptsblocked

https://gerrit.wikimedia.org/r/820908

Apparently there is an autoblockipblock event which is a subset of what's asked here. Not sure if it actually gets logged.

In T310390#8109041, @DLynch wrote:

Should we maybe pursue the new Metrics Platform for this? @phuedx?

I'm sorry for not having responded to this sooner.

Since we're currently working on migrating the EditAttemptStep, and the MobileWeb- and DesktopWebUIActionsTracking instruments to use the Metrics Platform Client so that we can assess the suitability of the schema and make adjustments as necessary, I think it's best to use the Event Platform for now.

In T310390#8144593, @Tgr wrote:

Apparently there is an autoblockipblock event which is a subset of what's asked here. Not sure if it actually gets logged.

FYI the schema was confirmed as deprecated in T267340: AutoblockIpBlock Event Platform Migration. It could easily be reused and updated though as there's no active instrument using it.

@DLynch

I finished taking a look through the proposed schema and just have a few questions and suggestions. See below:

• We should add in a block ID. This will enable us to look up more information about the block if needed in the logging table.
• Does it make send to also add performer.user_is_bot? Note: We'll also need to be able to distinguish if the user is logged-in or registered but we should be able to do that with the user_id field.
• You mentioned that platform and interface fields are redundant in this case, which makes sense because the proposed field includes the mobilefrontend value needed to distinguish those from desktop site events (and we are currently unable to make the distinction between devices pending resolution of T249944). Just some follow-up questions to clarify the meaning of the possible values:
  • interface = wikieditor, visualeditor or discussiontools would always be associated with desktop site visits, correct? I want to make sure we can use this field to look at desktop site vs mobilefrontend blocks in analytics.
  • What might be counted as other in this case?
• Block_types: I think the current schema covers the key information we need to track about block types (local vs global, fixed vs indefinite) but it would be useful to align as closely as possible with the block types being identified by the Growth team in T306018 for consistency.

Change 824578 had a related patch set uploaded (by Gergő Tisza; author: Gergő Tisza):

[mediawiki/extensions/GlobalBlocking@master] [WIP] Log block ID

https://gerrit.wikimedia.org/r/824578

Sorry, that patch was meant for the other task. Although I guess it's somewhat relevant to any block analytics work.

Re: block_expiry, I think I would go for using a null expiry for indefinite blocks. The current code for createaccount_blocked_user uses the MediaWiki representation as-is (in theory the string infinite but it could probably be something more esoteric, judging from the code in ApiResult::formatExpiry).

Change 824578 merged by jenkins-bot:

[mediawiki/extensions/GlobalBlocking@master] Log block ID

https://gerrit.wikimedia.org/r/824578

Change 832147 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/DiscussionTools@master] Add mw.track call when comment setup fails

https://gerrit.wikimedia.org/r/832147

Change 832148 had a related patch set uploaded (by DLynch; author: DLynch):

[mediawiki/extensions/WikimediaEvents@master] Log blocked edit attempts

https://gerrit.wikimedia.org/r/832148

Change 833442 had a related patch set uploaded (by DLynch; author: DLynch):

[operations/mediawiki-config@master] Register the editattempt_block schema

https://gerrit.wikimedia.org/r/833442

(I realized I'd forgotten to upload the config patch, not that it's actually needed until everything else is reviewed.)

Change 820908 merged by jenkins-bot:

[schemas/event/secondary@master] New schema: editattemptsblocked

https://gerrit.wikimedia.org/r/820908

Change 832147 merged by jenkins-bot:

[mediawiki/extensions/DiscussionTools@master] Add mw.track call when comment setup fails

https://gerrit.wikimedia.org/r/832147

Change 832148 merged by jenkins-bot:

[mediawiki/extensions/WikimediaEvents@master] Log blocked edit attempts

https://gerrit.wikimedia.org/r/832148

Change 833442 merged by jenkins-bot:

[operations/mediawiki-config@master] Register the editattempt_block schema

https://gerrit.wikimedia.org/r/833442

Mentioned in SAL (#wikimedia-operations) [2022-10-12T20:02:48Z] <samtar@deploy1002> Started scap: Backport for [[gerrit:833442|Register the editattempt_block schema (T310390)]]

Mentioned in SAL (#wikimedia-operations) [2022-10-12T20:03:11Z] <samtar@deploy1002> samtar and kemayo: Backport for [[gerrit:833442|Register the editattempt_block schema (T310390)]] synced to the testservers: mwdebug2002.codfw.wmnet, mwdebug1001.eqiad.wmnet, mwdebug1002.eqiad.wmnet, mwdebug2001.codfw.wmnet

Mentioned in SAL (#wikimedia-operations) [2022-10-12T20:08:31Z] <samtar@deploy1002> Finished scap: Backport for [[gerrit:833442|Register the editattempt_block schema (T310390)]] (duration: 05m 42s)

@MNeisler Huh, interesting. So, the country code is generated like this:

	private static function getCountryCode() {
		$request = RequestContext::getMain()->getRequest();
		$country = false;
		// Use the GeoIP cookie if available.
		$geoip = $request->getCookie( 'GeoIP', '' );
		if ( $geoip ) {
			$components = explode( ':', $geoip );
			$country = $components[0];
		}
		// If no country was found yet, try to do GeoIP lookup
		// Requires php5-geoip package
		if ( !$country && function_exists( 'geoip_country_code_by_name' ) ) {
			$ip = $request->getIP();
			if ( IPUtils::isValid( $ip ) ) {
				$country = geoip_country_code_by_name( $ip );
			}
		}
		return $country;
	}

As such, I'd speculate that this is users who're doing something intensely weird to their GeoIP cookie. Probably, since we're talking about blocked users, it's people who're throwing potential XSS vectors at the site to see if anything happens.

I could either add some validation to the logging code to make sure the country code is 2 characters, or I could leave it as-is if this is simple for you to filter out.