Thu, Nov 26
For very complex cases, those are likely a minority of users - that can be added to the override list as needed?
Notably the enwiki electcom shouldn't be the decider in how this software works - some users of it may want this functionality even if others don't; perhaps adding support to securepoll for differentiating block-types for restrictions though?
This has been broken for 3 years - is there noone that can work on this?
Tue, Nov 17
FYI enwiki discussion to hack this off for enwiki is open at https://en.wikipedia.org/wiki/MediaWiki_talk:Common.css#Fixing_the_accidental_return_of_decorative_quotations
Sun, Nov 8
I'd prefer this is fixed with T92795 , editing all content models is overkill for fixing the special create workflow to just bypass that
Nov 2 2020
Possible hack available:
Nov 1 2020
I under stand not wanting to pollute it with things that will eventually have to get cleaned up if becomes the canoical namespace name, but let the community manage it.
So its been a year, still no action - who is holding this up?
Oct 29 2020
Oct 20 2020
Oct 18 2020
@C.Syde65 what you are describing is exactly what this task is about - it is not actually restoring the view access on these pages to "administrators" - but to users with the permissions you mentioned.
@Tgr - we also allow all those 'crats to issue int-admin to anyone - but they are not supposed to do it unless the accounts have 2FA -- but they aren't able to actually check that so they just give it to anyone that claims they have 2FA, defeating the control (also not allowing audit to see if 2FA has been disabled). I expected this to be a bit borderline due to the way some projects (such as eswiki I mentioned above) give out 'crat to lots of users.
Oct 17 2020
For WMF wikis, we should probably expand the suppression policy to specifically allow for this type of removal. Feedback is welcome at https://meta.wikimedia.org/wiki/Talk:Oversight_policy#Expand_for_malicious_code_removal
Oct 16 2020
As the WMF-Legal project tag was added to this task, some general information to avoid wrong expectations:
Please note that public tasks in Wikimedia Phabricator are in general not a place where to expect feedback from the Legal Team of the Wikimedia Foundation due to the scope of the team and/or nature of legal topics. See the project tag description.
Please see https://meta.wikimedia.org/wiki/Legal for when and how to contact the Legal Team. Thanks!
Somewhat expect this to be controversial and need some weigh in. One the one hand, there is no way for these users to ensure this is in place before extending sensitive access - on the other hand some projects have a staggering amount of bureaucrats for some reason that this would extend the query access to (e.g. eswiki has 68 crats!). I'd say only on projects where bureaucrats can issues interface-admin, but that is currently all of the projects.
Oct 15 2020
Oct 14 2020
@PerfektesChaos those pages can be deleted for any type of reason (a common reason is "owner" request) - occasionally the owners then ask what the content was. Also keep in mind, that while those content models are designed for code, users can put anything in them - and letting admins investigate what happened by users is normally a good thing. If there is actual "dangerous" code on those pages, revision/page suppression can still be used.
Oct 13 2020
Sep 29 2020
Would want to see this allow for expiration as well, practice-wise on enwiki for example we have many groups that may create accounts - but depending on the reason for creation this is designed to only be for a specific event and should expire (of course the account could become auto confirmed in the interim). Perhaps even a default value / list such as on the block form could be used?
Sep 27 2020
@Gioguch that is what this request will do, it is "red" because it has the "new" class on it, it shouldn't need that class
Sep 20 2020
Even niche projects like meta-wiki got turned down for self-service during recent RfCs, mostly due to lack of a support process on 2FA.
@Evrifaessa any special reason why these rather light-weight access groups would need this, in light of the large lack of support for this feature and the existing opt-in that can already be used?
Sep 15 2020
Originally reported on enwiki page: https://en.wikipedia.org/wiki/MediaWiki_talk:Badtitletext#Red_link
Sep 7 2020
Are there any default (or wmf-specific) groups this will be added to, or will WMF communities need to request this be added to groups as needed?
Aug 20 2020
On enwiki we linked to the manual keyword list from MediaWiki:Cirrussearch-articletopic-invalid-topic - would much prefer that be any of the options for this to be system generated instead of a manually curated list, especially if it could change.
Aug 12 2020
I could see easily using bulk editing of the list to add/modify expiries - but I may be an edge case
I wasn't trying to be prescriptive in the format - and raw editing is usually more of a 'power editor' option. Right now it appears that the expiring data is completely lost if you use the raw editor though to do bulk changes (as it isn't included in the data feed) - so if you copy out thousands of rows and want to restore them you loose the existing expiries.
Aug 9 2020
I've updated the .js file on enwiki - flag for revert if it broke anything, if this resolved this issue feel free to assign to me and mark closed
Suggest a decline on this, as support for 2FA is still quite low - if someone really wants to test it they can go get rubber stamped at metawiki
Agree with jeblad, WebAuthn probably shouldn't be live on the production clusters right now, I'm not even seeing any end user guides.
Aug 7 2020
Aug 5 2020
T259721 has been proposed as a way to get around this problem
Jul 31 2020
Jul 27 2020
@Ragesoss thank you for the inforamtion update, however this is still a bug, user inputs shouldn't lead to a result of "internal server error" - at the least shouldn't this have better error handling and UX feedback?
Jul 22 2020
After some more investigation, this appears to be a https://www.mediawiki.org/wiki/Page_title_size_limitations condition only, with the interwiki prefix putting the link just over the limit - so now the condition is: the page title is not over the limit itself, but it is failing when linked via wikidata interwiki's - causing a failure for pages that are close to the maximum byte size
Jul 21 2020
Jul 20 2020
Probably just bad memory - think it was overlap with the not working/then working deleting of userjss/usercss
Is this a regression, feels like this was working before? Notably, non interface admins can rev-del mediawiki:*.[css|js] revisions, just not the entire page.
Jul 18 2020
Jul 15 2020
It could still be useful to have that page-summary working, but that isn't really what this specific ask seems to be.
That message suggests it is a summary for the entire page, not for the uploaded files section as seen in this image:
Jul 14 2020
Apologies, I was looking at too many things at once when I typed that!
Jul 13 2020
<s>@Sdkb can you be a bit more specific about the step-by-step to make the problem you want to solve occur? Simply following the link above didn't cause a problem, as it doesn't put me in to edit mode - we don't need to warn readers that they are not logged in.</s>
Jul 9 2020
@dbarratt there is already an admin option on blocks, to remove all sendmail access from the blocked user, this would be for an individual that doesn't want email from siteblocked users even if that option isn't selected.
I'm not sure this is really a good idea, but filed it for the other person. Users that are misusing email can be blocked from email, and if they are only bothering one person they can be manually muted (not to mention that in WMF wiki's if you don't use this option globally they can just email you from another project - even one where they are not blocked).
Jul 8 2020
Jul 7 2020
Jul 1 2020
This fix really should be on the browser side, phone numbers are normally written with a hyphen ("-", 0x2D) while in articles such as the example above with date ranges we normally use the en-dash ("–", 0x2013). Apple probably shouldn't be doing phone number translations on en dashes.
Jun 30 2020
See also T55315 where this was resolved, but only for editing page on visual editor.
Jun 29 2020
Jun 24 2020
@Wugapodes have you been able to revisit this?
Jun 17 2020
Jun 16 2020
That should be discussed locally, the community may prefer to keep both the h2 headings visible as long as possible, even if it will make narrow columns. Local discussions are welcome at: https://en.wikipedia.org/wiki/Template_talk:Protected_page_text
@Jdlrobson the sandbox change was pushed live in https://en.wikipedia.org/w/index.php?title=Special:Diff/962915348
Local template was updated, tests appear good - if further issues please reopen this task.
Jun 8 2020
Jun 7 2020
FYI: these are also failing using the legacy toolbar tool (see discussion linked in description)
Jun 6 2020
I'm not saying that is an overwhelming amount of feedback - but it is user feedback, there are only 14 subscribers on this task as well. Some of the feedback is that links to wikidata aren't as useful for readers as they are for editors, as wikidata isn't really reader content; but it is very useful as a tool for editors that incorporate the data in to the presentation content.
Recent discussions of this use with editors (c.f. https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/2020_left_sidebar_update&oldid=960644483#Move_Wikidata_to_%22In_other_projects%22 ) that make use of the link, where the feedback was to keep it in tools. Moving it around sections based on external factors may be confusing.
@Demian and @NordNordWest - a recent discussion with editors that use this link though that was a bad idea (c.f. https://en.wikipedia.org/w/index.php?title=Wikipedia:Requests_for_comment/2020_left_sidebar_update&oldid=960644483#Move_Wikidata_to_%22In_other_projects%22)
N.B. js hack added in enwiki MediaWiki:Monobook.js
May 31 2020
With a patch authored over a year ago, is there anyone else that can get this moving again?
@Tgr courtesy ping, is your "next" list timeline somewhat short?
May 30 2020
@Mooeypoo partial blocks already support blocking editing/creating as an action; and most projects will speedily delete pages that copy-and-paste as copyright issues. This is solely about the permission, as there have been instances where users are disruptive - but only about using the 'move' function - where prior to partial blocks would have been remedied with a traditional site block.