I wrote such a script as https://en.wikipedia.org/wiki/User:LFaraone/autounhide.js , although didn't spend much effort on it and am not experienced in writing MW user scripts.

@Daimona got bitten by this today, so was considering poking at it again, if you haven't had a chance to get started.

@Daimona it was on my queue but I hadn't gotten to it yet, my apologies for not releasing the task.

@Daimona, if you view the linked edits, you see that the actual edits and summaries are suppressed, but the contents of those edit summaries are visible via "examine" even if logged out.

First: I personally like reCAPTCHA, and think it provides a lot of value from a security/abuse PoV. Yet we need to consider carefully whether we can deploy it on Wikimedia projects as it stands.

@Jalexander: the workaround is to suppress the log event manually, no? Doesn't seem worth keeping private accordingly unless I am misunderstanding...

@Vogone: Could you open a new bug that makes explicit what functionality you can no longer use? Feel free to even assign it to me, but the specific ask in this bug is still implemented on master.

No, ombudsmen can NOT "actively suppress revisions".

I'm also interested, and intend to take a stab at implementing it sometime over the next few weeks. @Krenair @dpatrick let me know if you've started work on something worth basing my attempt off of.

Is this actually something worth implementing? HTTPS should be preferred as a transport in almost every case -- the performance downsides are low, and the security improvements are worthwhile for almost every use case that isn't inside a WMF datacentre (e.g. has a trusted path to gerrit)

I imagine for most purposes the auditability of the deletion log prevents abuse here. The amount of work involved to implement this request correctly makes me sceptical that it's worthwhile.

It looks like this was a behaviour change made in 2009 in rMWc2f7ea4d by @aaron

Should we just hide the log if you don't have deletedhistory?

Hmm this might be my regression.

In T123993#1999790, @bd808 wrote:

@lfaraone any objection to calling the project "cuos" so the overloaded "tools" word isn't part of the name?

There're also usability concerns — we'd need to make it non-annoying for Oversighters to view the log of recent suppressions.

The referenced change is not a change to SpecialUserrights.php. The change that added a reference to $user to that file is rMW99c4684f2cea (FYI @Pranavmk98 @Florian).

Yes, @yuvipanda is correct :)

Hmmm. It doesn't appear when not-logged-in, but does appear when you're a user without administrator rights.

In T92230#1940614, @Legoktm wrote:

Patch only covered Special:Log, still need something for action=history.

@Glaisher do you mean rewriting Special:RevisionDelete and porting all current users, or creating a new RevDel page with additional functionality?

@JohnLewis: What should we be tweaking? We're still seeing problems on various ArbCom/functionaries lists.

Should this be implemented in JS, server-side, or both? (JS default with a server-side fallback)

Sorry, my choice of wording was poor. I meant:

OK, so users with deleterevision will see checkboxes. SGTM.

For deleted pages, do we want to show checkboxes + change visibility for all users who have deletedhistory, or just users with suppressrevision? The use case for admins to change the visibility of revisions on an already-deleted page isn't obvious to me.

x-posting @Legoktm's example query from T111478 (duplicate)

{"exception":"[Exception DBQueryError] (/srv/mediawiki/php-1.26wmf21/includes/db/Database.php:1131) A connection error occured. \nQuery: SELECT  rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,rev_content_format,rev_content_model,user_name  FROM `revision` INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user))  WHERE rev_page = '16283969' AND rev_id IN ('679340073','679337192','679336675','679335920','679334110','679334014','679333987','679330491','679330449','679317447')   ORDER BY rev_id DESC \nFunction: RevDelRevisionList::doQuery\nError: 2013 Lost connection to MySQL server during query (10.64.48.28)\n\n[stacktrace]\n#0 /srv/mediawiki/php-1.26wmf21/includes/db/Database.php(1069): DatabaseBase->reportQueryError(string, integer, string, string, boolean)\n#1 /srv/mediawiki/php-1.26wmf21/includes/db/Database.php(1612): DatabaseBase->query(string, string)\n#2 /srv/mediawiki/php-1.26wmf21/includes/revisiondelete/RevDelRevisionList.php(74): DatabaseBase->select(array, array, array, string, array, array)\n#3 /srv/mediawiki/php-1.26wmf21/includes/RevisionList.php(84): RevDelRevisionList->doQuery(DatabaseMysqli)\n#4 /srv/mediawiki/php-1.26wmf21/includes/specials/SpecialRevisiondelete.php(172): RevisionListBase->reset()\n#5 /srv/mediawiki/php-1.26wmf21/includes/specialpage/SpecialPage.php(384): SpecialRevisionDelete->execute(string)\n#6 /srv/mediawiki/php-1.26wmf21/includes/actions/SpecialPageAction.php(77): SpecialPage->run(string)\n#7 /srv/mediawiki/php-1.26wmf21/includes/MediaWiki.php(458): SpecialPageAction->show()\n#8 /srv/mediawiki/php-1.26wmf21/includes/MediaWiki.php(255): MediaWiki->performAction(Article, Title)\n#9 /srv/mediawiki/php-1.26wmf21/includes/MediaWiki.php(682): MediaWiki->performRequest()\n#10 /srv/mediawiki/php-1.26wmf21/includes/MediaWiki.php(476): MediaWiki->main()\n#11 /srv/mediawiki/php-1.26wmf21/index.php(41): MediaWiki->run()\n#12 /srv/mediawiki/w/index.php(3): include(string)\n#13 {main}\n"}

mysql:wikiadmin@db1072 [enwiki]> explain SELECT  rev_id,rev_page,rev_text_id,rev_timestamp,rev_comment,rev_user_text,rev_user,rev_minor_edit,rev_deleted,rev_len,rev_parent_id,rev_sha1,rev_content_format,rev_content_model,user_name  FROM `revision` INNER JOIN `page` ON ((page_id = rev_page)) LEFT JOIN `user` ON ((rev_user != 0) AND (user_id = rev_user))  WHERE rev_page = '16283969' AND rev_id IN ('679340073','679337192','679336675','679335920','679334110','679334014','679333987','679330491','679330449','679317447')   ORDER BY rev_id DESC;
+------+-------------+----------+--------+------------------------------------+-------------+---------+--------------------------+------+-------------+
| id   | select_type | table    | type   | possible_keys                      | key         | key_len | ref                      | rows | Extra       |
+------+-------------+----------+--------+------------------------------------+-------------+---------+--------------------------+------+-------------+
|    1 | SIMPLE      | page     | const  | PRIMARY                            | PRIMARY     | 4       | const                    |    1 | Using index |
|    1 | SIMPLE      | revision | ref    | PRIMARY,rev_page_id,page_timestamp | rev_page_id | 4       | const                    |   10 | Using where |
|    1 | SIMPLE      | user     | eq_ref | PRIMARY                            | PRIMARY     | 4       | enwiki.revision.rev_user |    1 | Using where |
+------+-------------+----------+--------+------------------------------------+-------------+---------+--------------------------+------+-------------+
3 rows in set (0.00 sec)

The English Wikipedia Arbitration Committee moved from arbcom.en.wikipedia.org to arbcom-en.wikipedia.org (see T33335). As long as the new hostname continues to work (the one that isn't a subdomain of en.wikipedia.org), we're fine with the move.

In T106282#1463782, @Anomie wrote:

Changing this would be a backwards compatibility break, which isn't something to do lightly. But this also seems likely to be a little-used module, so it's not necessarily impossible.

To proceed, we'd need to try to determine how many clients are actually using checkuserlog to weigh the advantage of improved consistency against the disadvantage of breaking all existing clients.

In T87217#1043145, @Steinsplitter wrote:

In T87217#1041222, @tommorris wrote:

If one is using tethered mobile broadband from Three (a UK mobile operator) using an Android handset to provide a personal hotspot, every slight jolt in mobile connectivity led to a new IPv4 address being granted. When I used to commute by train, the loss of an OTRS session every time one went through a tunnel for a second or two was fatal to my ability to handle any tickets.

Because your have a new ip when reconnecting.

I think the IP checking is a useful security measure and should not be disabled.

In T87217#998470, @pajz wrote:

Second Rjd0060's comment here. OTRS can be configured to stop constantly comparing your current ip with your 'login ip' (see my first comment), and, of course, technically, we could change that setting, but since I/we have no idea about the potential security implications, ops has to make that call IMHO.

Does IP-affinity really provide a lot of security benefits? Or are
there other problems with OTRS that make this problematic... :(

This is fixed in Mailman 2.1.18, see the release announcement:

The from_is_list feature introduced in 2.1.16 is now unconditionally available to list owners. There is also, a new Privacy options -> Sender filters -> dmarc_moderation_action feature which applies to list messages where the From: address is in a domain which publishes a DMARC policy of reject or possibly quarantine. This is a list setting with values of Accept, Wrap Message, Munge From, Reject or Discard. There is a new DEFAULT_DMARC_MODERATION_ACTION configuration setting to set the default for this, and the list admin UI is not able to set an action which is 'less' than the default. The prior ALLOW_FROM_IS_LIST setting has been removed and is effectively always Yes. There is a new dmarc_quarantine_moderation_action list setting with default set by a new DEFAULT_DMARC_QUARANTINE_MODERATION_ACTION configuration setting which in turn defaults to Yes. The list setting can be set to No to exclude domains with DMARC policy of quarantine from dmarc_moderation_action.

dmarc_moderation_action and from_is_list interact in the following way. If the message is From: a domain to which dmarc_moderation_action applies and if dmarc_moderation_action is other than Accept, dmarc_moderation_action applies to that message. Otherwise the from_is_list action applies.