Page MenuHomePhabricator

Recent changes wrongly show as "b" for bot after update
Closed, DeclinedPublic

Description

Updated our wiki from 1.30 to 1.31. Ran update.php, and rest of wiki seems to be working fine.

After this, when I run rebuildrecentchanges.php or rebuildall.php, these scripts wrongly mark all prior recent changes to "b" for bot. New recent changes are showing as non-bot, as they should. Confirmed in recentchanges table that they are marked as bot there, and when I run a query to change them from 1 to 0 the listing on special:recentchanges becomes right. I can recreate this consistently on our wiki.

We run rebuildall.php as a cron overnight, so I know this was not happening before the update. With the "b" the edits are hidden by default in the recent changes.

One unusual bit of setup we have is that all users are part of a group CCMDB_legit and we have some user rights set up around this. However, I have a sister wiki with the same group and users (but login protected), and it doesn't add the "b" to recent changes.

We run SMW 2.5.6, though I can't see how that would be related. Php version is 7.1.17, hosted on Dreamhost.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald Transcript

@Tenbergen: Can you paste your user group config for your wiki here so that we can try to reproduce?

Are you talking about a section of the local settings?

  • Original message --------From: kaldari <no-reply@phabricator.wikimedia.org> Date: 2018-08-21 13:52 (GMT-06:00) To: ttenbergen@gmail.com Subject: [Maniphest] [Commented On] T199744: Recent changes wrongly show as "b" for bot after update

kaldari added a comment.

@Tenbergen: Can you paste your user group config for your wiki here so that we can try to reproduce?
TASK DETAILhttps://phabricator.wikimedia.org/T199744
EMAIL PREFERENCEShttps://phabricator.wikimedia.org/settings/panel/emailpreferences/
To: kaldari
Cc: kaldari, Tenbergen, Aklapper, kostajh, MMiller_WMF, Jayprakash12345, Jrbranaa, RHo, Wong128hk, Dcljr

Yes, the settings related to $wgGroupPermissions in your LocalSettings.php, especially any related to the bot user right or user group. I don't imagine this is related to the bug, but it's good to eliminate that variable since you mentioned it.

We run rebuildall.php as a cron overnight

Out of curiosity, why do you do that? From my understanding, rebuildall.php is meant to be run rarely, to fix serious problems, not to be run daily. I haven't heard of anyone else doing this.

Sorry about the delay. below are the permissions from the localsettings.php. There are a lot of them, some are likely not necesary. We used to run this instance as a login-to-view/edit wiki, and then changed it to a public one some time ago, but I never reviewed which of these could just go. CCMDBlegit is the group you need to be part of to edit. It's a leftover from when we also needed to make holders of former accounts unable to view content.

  1. ------------------------------------------------------------------------
  2. Group Permission Stuff - implements a way to remove users
  3. from ability to view when they leave.

$wgGroupPermissions['*']['read'] = true;

$wgGroupPermissions['*']['createpage'] = false;
$wgGroupPermissions['*']['createtalk'] = false;
$wgGroupPermissions['*']['createaccount'] = false;
$wgGroupPermissions['*']['edit'] = false;
$wgGroupPermissions['*']['editmyoptions'] = false;
$wgGroupPermissions['*']['editmyprivateinfo'] = true;
$wgGroupPermissions['*']['editmyusercss'] = false;
$wgGroupPermissions['*']['editmyuserjs'] = false;
$wgGroupPermissions['*']['editmywatchlist'] = false;
$wgGroupPermissions['*']['writeapi'] = false;
$wgGroupPermissions['*']['viewmyprivateinfo'] = false;
$wgGroupPermissions['*']['viewmywatchlist'] = false;

$wgGroupPermissions['user']['read'] = false;
$wgGroupPermissions['user']['edit'] = false;
$wgGroupPermissions['user']['createaccount'] = false;
$wgGroupPermissions['user']['upload'] = false;
$wgGroupPermissions['user']['passwordreset'] = false;
$wgGroupPermissions['user']['createtalk'] = false;
$wgGroupPermissions['user']['createpage'] = false;
$wgGroupPermissions['user']['movefile'] = false;
$wgGroupPermissions['user']['move'] = false;
$wgGroupPermissions['user']['reupload'] = false;
$wgGroupPermissions['user']['changetags'] = false;
$wgGroupPermissions['user']['applychangetags'] = false;
$wgGroupPermissions['user']['minoredit'] = false;
$wgGroupPermissions['user']['move-categorypages'] = false;
$wgGroupPermissions['user']['move-subpages'] = false;
$wgGroupPermissions['user']['move-rootuserpages'] = false;
$wgGroupPermissions['user']['reupload-shared'] = false;
$wgGroupPermissions['user']['purge'] = false;
$wgGroupPermissions['user']['sendemail'] = false;
$wgGroupPermissions['user']['writeapi'] = false;
$wgGroupPermissions['user']['editmyprivateinfo'] = true;

with above as false can't reset passwords or set up new user

$wgGroupPermissions['CCMDB_legit']['edit'] = true;
$wgGroupPermissions['CCMDB_legit']['read'] = true;
$wgGroupPermissions['CCMDB_legit']['upload'] = true;
$wgGroupPermissions['CCMDB_legit']['suppressredirect'] = true;
$wgGroupPermissions['CCMDB_legit']['createpage'] = true;
$wgGroupPermissions['CCMDB_legit']['movefile'] = true;
$wgGroupPermissions['CCMDB_legit']['move'] = true;
$wgGroupPermissions['CCMDB_legit']['reupload'] = true;
$wgGroupPermissions['CCMDB_legit']['minoredit'] = true;
$wgGroupPermissions['CCMDB_legit']['editmyoptions'] = true;
$wgGroupPermissions['CCMDB_legit']['editmyprivateinfo'] = true;
$wgGroupPermissions['CCMDB_legit']['editmywatchlist'] = true;
$wgGroupPermissions['CCMDB_legit']['writeapi'] = true;
$wgGroupPermissions['CCMDB_legit']['viewmyprivateinfo'] = true;
$wgGroupPermissions['CCMDB_legit']['viewmywatchlist'] = true;
$wgGroupPermissions['CCMDB_legit']['sendemail'] = true;
$wgGroupPermissions['CCMDB_legit']['delete'] = true;

RE: Rebuildall.php, we use SMW with out mediawiki, and between SMW and MW we used to have some stuff not update automatically. The problems and tweaks to its solution have been around our instances for years, so I am afraid I can't remember why specifically we run rebuildall. The problems we were encountering were things like making sure that SMW driven content gets updated, wanted tables and wanted categories and stuff get update, and similar things. I have done a better job logging our changes in more recent years, but I think adding rebuildall pre-dates that.
https://www.mediawiki.org/wiki/Topic:Tu9jxpne4mvgsl36
might have been it.

I'm afraid that it's very hard to figure out what happened and why at this point, but since your situation is such a confluence of odd edge-case-y things and it's never been reported by anyone else, I'm going to give up on figuring out what happened here.

My best theory is that your LocalSettings.php assigned bot rights to a lot of users at the time that you ran the script, but the LocalSettings that you pasted doesn't do that. I'm out of ideas, but I also think this is very unlikely to ever happen again, and we can reopen this task if it does.