Last modified: 2012-12-18 10:53:06 UTC
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 | +----------+
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; 2. Store the above information in a temporary table (or in memory) 3. Destroy and rebuild the recentchanges table 4. 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 | +----------+--------------+ | 428 | 0 | | 37 | 1 | +----------+--------------+ $wgUseRCPatrol=$wgUseNPPatrol=false; gives the same. Commenting it out entirely gives +----------+--------------+ | COUNT(*) | rc_patrolled | +----------+--------------+ | 385 | 0 | | 80 | 1 | +----------+--------------+ 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)
