|Resolved||mforns||T134790 Extract edit oriented data from MySQL for simplewiki|
|Resolved||None||T120037 Vital Signs: Please provide an "all languages" de-duplicated stream for the Community/Content groups of metrics|
|Resolved||None||T120036 Vital Signs: Please make the data for enwiki and other big wikis less sad, and not just be missing for most days|
|Open||None||T130256 Wikistats 2.0.|
|Duplicate||mforns||T134793 User history in hadoop|
|Resolved||Ottomata||T134502 Propose evolution of Mediawiki EventBus schemas to match needed data for Analytics need|
|Resolved||Ottomata||T137287 Update MediaWiki hooks to generate data for new event-bus schemas|
|Declined||JAllemandou||T134792 Spike - Slowly Changing Dimensions on Druid|
- Mentioned In
- T60596: The ArticleRevisionVisibilitySet hook should provide information on what in the revision is being hidden
T138268: Mediawiki changes to publish data for analytics schemas
- Mentioned Here
- T134502: Propose evolution of Mediawiki EventBus schemas to match needed data for Analytics need
In T134502#2326641 I wrote about how to implement user_blocks_change event:
The hook we would be able to use now to get this info is > BlockIpComplete. As is, this hook does not provide us with the previous state. We'd have to make modifications to SpecialBlock.php to get this. The code in maybeAlterFormDefaults() does look up previously saved block info from the db before submitting the form. We could save the $block object returned by Block::newFromTarget( $this->target ); on the SpecialBlock object, and then pass it to the BlockIpComplete hook later.
But doh, this won't work! The BlockIpComplete hook is run from [[ https://github.com/wikimedia/mediawiki/blob/master/includes/specials/SpecialBlock.php#L789 | processForm() ]], which is static, I guess called by some other place deep in Mediawiki. Plus maybeAlterFormDefaults is for presenting the form to the user, not intaking it, so it would be premature there anyway.
So, now I'm not sure how to do this without an extra db lookup during form submission. @aaron, thoughts?
Ok, it looks like processForm() does actually look up the previous block before submitting, if an initial insert fails.
The $currentBlock is altered and then $currentBlock-update() is called. I think I'll need to implement Block::clone in order to do $previousBlock = clone $currentBlock so that I have an untouched object I can work with once I get to emitting BlockIpComplete. TODO!