@kostajh looks like so far the issue has been people following those links with the ?show argument, checking before closing this.
Fri, Oct 19
When was this move to force-on? The behavior for the last years has been that it could be activated, but minimizing and dismissing it would keep it off unless you specifically turned it back on with the 'curate article' link?
At https://en.wikipedia.org/w/index.php?title=Wikipedia:Village_pump_(technical)&oldid=864788191#How_can_I_permanently_hide_the_page_curation_rightside_toolbar we have at least one user reporting that they are no longer able to persistently DISMISS the triage toolbar, in that it keeps reappearing when unwanted.
@Deskana, if the advanced control panels could use a named identifier, I suspect enwiki would likely just hide it with css for newbies based on the autoconfirmed or other group membership css's - and that would likely address itwiki's concern as well, right now the naming appears to be dynamic (e.g. id="ooui-28")
Thu, Oct 18
Checked over deleted edits, 10 for 10 got their index directive from VE as well. Even being able to hide the advanced control would help and then could be managed by communities - however it appears to not use a distinctive ID, instead using generated OOUI--nn ID's that could possibly also be used elsewhere.
Wed, Oct 17
en wiki (https://en.wikipedia.org/w/index.php?title=Wikipedia:Edit_filter_noticeboard&oldid=864548831#VisualEditor) has created an edit filter to stop the rampant misuse of indexing in user space, that upon review we think is from this tool.
Mon, Oct 15
OK I'm following you now, you expect to see the before and after diff, plus the revision compiled text below. I don't see that either, but I can't recall if I used to see it in this view.
Diff: https://test.wikipedia.org/w/index.php?title=T205578_example&diff=next&oldid=362682&unhide=1 works for me as well.
@Daimona - worked for me (example here: https://test.wikipedia.org/w/index.php?title=T205578_example&oldid=362683&unhide=1 on testwiki) - goes right to the deleted text.
Sat, Oct 13
AWB currently supports BotPassword logons, information on usage included above, closing.
Thu, Oct 11
@MMiller_WMF while that is the 'default' - it can be set per project at MediaWiki:Logentry-pagetriage-copyvio-insert
Wed, Oct 10
Ooops thanks for the note @Daimona - been staring at too many other things today!
Fri, Oct 5
This field is again showing, populated, and is able to be queried even without a filter hit, and can be accessed without even logging on. Example: https://de.wikipedia.org/wiki/Spezial:Missbrauchsfilter/examine/263782881 shows this tickets authors confirmation datestamp.
Thu, Oct 4
Thank you, looks good - tested on Group2 projects.
Wed, Oct 3
Tue, Oct 2
I could be the only one hung up on this, just think it shouldn't even claim to be determining a legal status (violation of a copyright), just an information status (possible copied text) or the like.
@eranroz Tthe trial showed using tags was successful , but when it was time to go live there wasn't a good use-case for tags to be used. I suggest opening a short discussion to see what the community wants - but I don't have any specific objection.
Sun, Sep 30
@Izno Please note, we think making a bot to sync json pages to js pages is far from ideal, and having this be able to work server-side in a way that "data" can be edited outside of "code" would be much preferred. For anyone following you can check on the bot build progress here: https://en.wikipedia.org/wiki/Wikipedia:Bots/Requests_for_approval/MusikBot_II_2
Thu, Sep 27
Example on testwiki:
Sep 16 2018
@IKhitron ok, I must have misunderstood you , I though you wanted to allow an existing group to use the 'editcontentmodel' right and were denied.
To follow up from project talks, I suggest the labeling for this is updated from "copyvio" to "copydetect" or the like, especially as we are relying on a third party - our labeling should be neutral (this text appears to have been copied from somewhere else) as opposed to making a legal claim (this text has violated a copyright law).
This shouldn't be blocking using templatestyles, when creating a new template style (e.g. https://test.wikipedia.org/wiki/Template:389573/styles.css) is is already in the correct content model.
Sep 14 2018
Sep 7 2018
Is that the entire page? Where are all the parts that were in "signature" and "email options" now? Is "restore defaults" still down the page?
Sep 4 2018
How is "copyright" of submissions being validated? From a much earlier review it appeared that this was only looking for "unoriginal" text, not text that was actually violating a copyright as its labeling suggests?
Aug 29 2018
What are the next steps here - will someone from the dev community claim this and work on it?
Aug 28 2018
In order for oversighters (who are in almost all cases also admin) to suppress they will need to be able to see the deleted history, which they can not now.
@Urbanecm can you link to a community discussion in support of this new group?
@Teles right now on most configuration you must be sysop AND intadmin to use viewdelete on jss/css pages.
@stjn, FYI if you are an intadmin, and NOT also an admin (or otherwise a holder of viewdelete) - you can't see these deleted pages either; I expected that behavior - just FYI
I think its a problem, as it gives interface administrator the ability to hide revisions from most everyone (oh noes its 'superdelete') - limiting the transparency of what they did.
Enwiki discussion that brought this up: https://en.wikipedia.org/w/index.php?title=Wikipedia:Bureaucrats%27_noticeboard&oldid=856932527#View_delete_problem
Aug 27 2018
I think "delete" alone should be enough here, e.g. if there is abusive js in some place and the page gets deleted, you don't want it restored by people that can't make it normally.
Aug 26 2018
While it looks like it was declined(?) before in T54053, none of the moved_to and moved_from protection values are actually being populated, are these deprecated and should just be removed? Example: https://test.wikipedia.org/wiki/Special:AbuseFilter/examine/398011
Aug 24 2018
From discussion on T202597 -
@wctaiwan as an immediate workaround, you can do what we did on enwiki: create a batch of empty shells.
Aug 23 2018
@Vogone, this could be re titled - unless you want to build a community consensus on metawiki for changing their group only - I think in the discussion so far we've identified that this is really a "global" problem that could be fixed a few ways.
True, however that access allows for much more than only creating massmessage delivery lists. I'd 100% support a configuration that allows massmessage people to use that special createlist function without also needing to be able to change content models on every page as the default.
This is not an "error" it is by design. Simply being able to use the massmessage extension doesn't require changing content models.
Aug 20 2018
May be a solution for T6469
Aug 19 2018
Aug 18 2018
@Huji how was this determined? Did you manage to query every filter on every project?
Aug 17 2018
@Huji enwiki 635 has been updated as well (note it was a deleted filter)
It looks like the related default text for MediaWiki:Group-otrs-member-member does not exist either
and for any project that localized links for these messages:
I changed enwiki's 642; but as the primary purpose of this group is to feed a variable for abusefilters - getting a handle on what is impacted should not be delayed
Not sure if there is a good way to search every projects abuse filter details, after a quick search though I found these on 4 large sites:
Aug 16 2018
Note, this group is primarily used by various abuse filters, they should be checked to see if this change will require filter updates.
Aug 5 2018
As there is already special checks in place for userjs/usercss could this also allow for deletion - as the mediawiki namespace normally has its own protection it won't allow arbitrary creation (unlike userspace).
@Tgr agree it could be desirable - please correct me if I'm wrong but after this change this scenario is created:
Followup #2: Will global renamer's that are not local interface admins still be able to move user .js/.css subpages? If not, how will these fail?
Following up on discussion from enwiki: Will local sysops's still be able to delete css/js pages if they are not also able to edit them? Specifically in relation to user css/user js pages I suspect this is going to increase the number of users seeking access. Would it be difficult to allow admins to continue to be able to delete? I'm guessing same problem will occur for oversighting these pages? That is if an OS is not also an interface admin will they be unable to perform oversight operations on these pages?
Jul 27 2018
With this being removed from sysop, is it actually also being ADDED to techadmin - or will it be orphaned?
Jul 20 2018
This sounds like a very expensive way to run filters, how would it scale? Can someone show a mockup filter for when there are an example 10 different pairs of these restrictions? Or would you implement a separate filter for each group? This also doesn't seem to address discussion type pages - perhaps more filters for that?
Jul 18 2018
@Tgr if communities need to opt-in to enable this of their bureaucrats the project level RfCs may take some time (a month is not unusual for a project like enwiki) - as the final specification for what access is being removed from sysop, and which access is being included by default in local-interfaceadmin ?
Jul 9 2018
@Ajraddatz my hopes would be that it would be like botpasswords, where basically you could log on with multiple passwords if you opt in to it, and when you opt in to it you can choose what access is available under your opt. You could lock certain passwords to certain IP's, make some edit-only, etc. Put everything entirely in control of the editor.
Jul 8 2018
See also T176033
Jul 3 2018
Jul 2 2018
Possibly related to T173977 ?