I don't think this is needed, given the REVISIONUSER magic word:

When using rollback, the user is presented with the save form, which means that T109032 would also fulfill this request

The current logic for system defined tags is in ContentHandler.php (the getChangeType function) which has as inputs the old content, the new content, and flags for the edit. To track addition of external links, it would also need the difference in the revisions, unless the filter should only look for a mere increase in the number of links.

Perhaps such filter names should be expressly disallowed through the isTagNameValid check?

I think this was already done - changetags is needed to change tags arbitrarily, and applychangetags is needed to apply tags to one's edits? Unless I am misunderstanding the task

@Cenarium do you still intend to work on this?

Is this still desired / is there consensus to implement this change?

By "rearrange table columns", do you mean like dragging them to move in a user defined manner or sorting the columns based on a value in a specific row (as opposed to sorting rows based on the value in a specific column)

For each tag, getting all of the properties ( https://en.wikipedia.org/w/api.php?action=query&list=tags&tgprop=displayname|description|hitcount|defined|source|active&tglimit=max ) returns

1. A "name" for the tag
2. A "displayname" for the tag
3. A "description" for the tag
4. A "hitcount" for the tag

As far as I can tell, if the tag is still active, it also returns an empty defined and active fields, as well as a source that is an array of (currently) either extension, manual, or both. If the tag is inactive, the source array is empty, and the defined and active fields are omitted

Unlike Special:Move, which is an UnlistedSpecialPage, deleting a page is done with a FormlessAction than uses Article.php's delete function, which has the comment # This code desperately needs to be totally rewritten. Would it make sense / be okay to convert deleting from a formless action to a special page?

The easiest would be to add a new readonly field, and it would (in my view) also be the least confusion. There are currently 3 fields to the form: the page title (read only), the new content model (dropdown menu) and the reason (text field). I suggest adding a readonly field with the current content model directly below the page title, both to group the readonly fields together and so that the current model is visible when the menu is opened. Thoughts?

In T227705#5330497, @Huji wrote:

I still think someone else with more experience should give this some consideration; I continue to think that the help message should be wiki-specific, and therefore it should not be handled through the code base.

I've added a note about Special:BlankPage

@sbassett any updates?

There is similar code in SpecialNewpages.php that allows filtering that.

Seems like a similar task already exists

Waiting for it to be added

Sorry, didn't mean to add that

Per comment on https://gerrit.wikimedia.org/r/517775: Sorry, my fault, should now be fixed. - things appear to be working again, https://gerrit.wikimedia.org/r/517775 was successfully merged

As did https://gerrit.wikimedia.org/r/#/c/mediawiki/extensions/CentralAuth/+/522211/, which shouldn't have failed by any means - all it does is replace a space with an underscore in a string

@Huji both this and T224816 failed to merge, with the following error:

I tried to figure out how this could be done, but ran out of time after a few hours. But, for whomever works on this, a potential implementation is, similar to ArticleCompileDeletionTag.php, also compile maintenance tags, and then use the current icon logic (shown below, retrieved from ext.pageTriage.listItem.underscore) to include a case for maintenance tags.

<div class="mwe-pt-status-icon">
	<% if ( is_draft ) { %>
		<img src="<%- mw.config.get( 'wgExtensionAssetsPath' ) + '/PageTriage/modules/ext.pageTriage.views.list/images/icon_not_reviewed.png' %>" width="21" height="21" />
	<% } else if ( afd_status == "1" || blp_prod_status == "1" || csd_status == "1" || prod_status == "1" ) { %>
		<img src="<%- mw.config.get( 'wgExtensionAssetsPath' ) + '/PageTriage/modules/ext.pageTriage.views.list/images/icon_marked_for_deletion.png' %>" width="21" height="21" />
	<% } else if ( patrol_status != "0" ) { %>
		<img src="<%- mw.config.get( 'wgExtensionAssetsPath' ) + '/PageTriage/modules/ext.pageTriage.views.list/images/icon_reviewed.png' %>" width="21" height="21" />
	<% } else { %>
		<img src="<%- mw.config.get( 'wgExtensionAssetsPath' ) + '/PageTriage/modules/ext.pageTriage.views.list/images/icon_not_reviewed.png' %>" width="21" height="21" />
	<% } %>
</div>

@Dovi the first 2 requests have been merged.

In T226938#5325616, @Huji wrote:

@DannyS712 feel free to add me as a reviewer for the remaining patches.

@Tgr then can we add another parameter (ex HTML boolean &NoTemplateStyles=foo)?

If this is on a wikimedia foundation wiki, it may be because the interwiki map is controlled globally from meta

In vector, and safemode fixed it, as did commenting out my common.js, so its a script issue. Sorry

@Aklapper sorry, I thought that since you uploaded a patch to solve this you had just overlooked claiming it.

In T227595#5318444, @dbarratt wrote:

As part of the migration, we could reverse the ids, so the filter id would be the page id. For instance AbuseFilter:Test edits might have a page id of 123456 so that would be the filter id. I think there are pros and cons to the id as the title (like Wikidata) and using the page id (like Structured Data on Commons)

Points to discuss:

• How will "notes" be implement: using the talk page would be the easiest, but currently notes can only be edited by users who can edit filters, and using the talk page would either allow other users to edit notes or (by protecting the page to avoid this) defeat the purpose of the talk page
• How should flags and tags be stored? Suggestion: similar to ProofreadPage. Looking at the content of a proofread page page (example) shows the use of a custom tag: <pagequality level=\"3\" user=\"DannyS712\" />. Thus, something like <abusefilter flags=\"enabled, private\" actions=\"warn, tag\" message=\"abusefilter-warn\" tag=\"test edits, example tag\" /> could be used
• How should filter descriptions vs ids be stored? Currently, filters are "named" based on a unique integer id (abuse filter 1, 2, etc) and then a text description is set. If the "pages" are now stored as AbuseFilter:1, AbuseFilter:2, etc with a description specified on the page, we lose the benefit of a namespace in terms of utilizing page names. However, if we use AbuseFilter:Test edits, AbuseFilter: LTA, etc then how are filter ids stored, and how are they connected to pages?
• Content handler editor: This namespace will likely need a custom edit form (example: the custom edit form for mass message lists)

@Daimona added your project due to presence at T62588

Merging to wider scope task, see comments at T62588#5126449 and T227595#5317929

This would also allow T62588 - should that be merged? I suggested this as a potential route there:

@Jeff_G that's because the template is still fully protected. You can only edit pages that are template protected. See the current list.

I'm not sure that a phabricator task is needed for this. Any sysop can create a new tag and manually apply it to revisions