Page MenuHomePhabricator

rebuildrecentchanges.php should preserve rc_patrolled column
Open, LowPublicFeature

Description

Please make maintenance/rebuildrecentchanges.php preserve the rc_patrolled column in the recentchanges table. When you need to rebuild recent changes (e.g., after a big import), you shouldn't have to lose your patrolling information. At least make this an option. Thanks.

Case study:

Step 1:

mysql> select count(*) from vpw_recentchanges where rc_patrolled = 1;
+----------+

count(*)

+----------+

4807

+----------+

Step 2: mark a bunch of articles as patrolled

Step 3:

mysql> select count(*) from vpw_recentchanges where rc_patrolled = 1;
+----------+

count(*)

+----------+

4812

+----------+

Step 4:

$ php rebuildrecentchanges.php

Step 5: The newly patrolled article data is lost:

mysql> select count(*) from vpw_recentchanges where rc_patrolled = 1;
+----------+

count(*)

+----------+

4807

+----------+


Version: 1.19.3
Severity: enhancement

Details

Reference
bz19466

Event Timeline

bzimport raised the priority of this task from to Low.Nov 21 2014, 10:40 PM
bzimport set Reference to bz19466.
bzimport added a subscriber: Unknown Object (MLST).

Patrolling information is only stored in the recentchanges table and nowhere else, so this is impossible by definition.

It is NOT impossible. rebuildrecentchanges.php is a PHP script, so it could save and restore the patrolling information:

  1. select (columns) from vpw_recentchanges where rc_patrolled = 1;
  1. Store the above information in a temporary table (or in memory)
  1. Destroy and rebuild the recentchanges table
  1. Restore rc_patrolled from the temporary table into recentchanges

(Well, there should be a --flag then to say that "yes, even though I'm
frustrated with the current recentchanges table, I still want to refer
to some parts of it when rebuilding.")

P.S., Some things that are bugging me:
In tables.sql we see:

  • If the Recent Changes Patrol option is enabled,
  • users may mark edits as having been reviewed to
  • remove a warning flag on the RC list.
  • A value of 1 indicates the page has been reviewed. rc_patrolled tinyint unsigned NOT NULL default 0,

Well, in English parlance, "reviewed" is a lot different than
"patrolled". OK, never mind that.

And mainly, in LocalSettings.php I have
$wgUseRCPatrol=$wgUseNPPatrol=$wgGroupPermissions['sysop']['autopatrol']=false;
after running rebuildrecentchanges.php I get:
SELECT COUNT(*),rc_patrolled FROM recentchanges GROUP BY rc_patrolled
+----------+--------------+

COUNT(*)rc_patrolled

+----------+--------------+

4280
371

+----------+--------------+
$wgUseRCPatrol=$wgUseNPPatrol=false; gives the same.
Commenting it out entirely gives
+----------+--------------+

COUNT(*)rc_patrolled

+----------+--------------+

3850
801

+----------+--------------+
I just don't get it. What do I need in LocalSettings.php to say "my
wiki really doesn't care about the patrol business"?
OK, I understand that with
$wgUseRCPatrol=$wgUseNPPatrol=false my users will never be bothered
with it, but why is rc_patrolled still getting different values, and
even after running rebuildrecentchanges.php? Yes, I suppose I could
keep on analyzing to find out where the different values are being
generated, but as I use $wgUseRCPatrol=$wgUseNPPatrol=false; it is
really just an academic question, as my users will never know the difference.

I just lost all information about patrolled edits in RecentChanges after running rebuildrecentchanges.php. This should not happen I guess. (MW 1.19.3)

Aklapper changed the subtype of this task from "Task" to "Feature Request".Feb 4 2022, 11:01 AM