MediaWiki talk:Group-sysop.js

Latest comment: 9 years ago by MSGJ in topic Protected edit request on 11 July 2014

Note edit

This MediaWiki page was designed for us to be able to do sysop-only javascript (such as things for deletion/protection pages). Common.js includes this iff you're a member of the sysop group. ^demon[omg plz] 12:45, 8 August 2007 (UTC)Reply

I can't believe we have had this all along and have not been using it. I like the first tool, and I hope there is consensus for more such tools in the future. 1 != 2 17:47, 14 October 2007 (UTC)Reply

Order edit

Very practical this. Minor detail, could the order of boxes be changed? It makes more sense have the order be restore, invert selection, reset. I am not that good at code so I don't want to mess with it.Garion96 (talk) 16:20, 14 October 2007 (UTC)Reply

CSD AutoReason edit

Would anyone object to me adding my auto-reason stuff for CSD into this for all admins? ^demon[omg plz] 13:06, 16 October 2007 (UTC)Reply

I object for one reason only: it forces a standard values table for all administrators. As you can see at User:Nihiltres/monobook.js, I use the script, but I've substituted it onto my page, modified some of the reasons, and added others. For example, one of the ones I use often is a second definition for particular cases of CSD G7, the "page blanked by author" clause... I have a custom definition that I use in that context, because the reason for deletion is then more transparent.
If there's some method to personally customize (or at least add to) the values table the script uses, I would completely support adding the script to this page. Nihiltres(t.l) 15:07, 16 October 2007 (UTC)Reply
In general, I note that objections may only occur after additions are made and sysops start seeing how it affects what they are doing. So any consensus formed on talk prior to the addition of new items is never more than tentative. I have no opinion on this one, because I don't know either 1) what it will do or 2) whether I will consider it to have made things better or worse. It would also be optimum if any code added here has explicit "opt out" instructions to make it not function for any specific sysop that doesn't want it. GRBerry 17:04, 16 October 2007 (UTC)Reply
I think it is a good idea, and I think it is feasible to add instructions on how to override the default values, not sure about that. If a consensus forms against it then it can be removed. It does not force anyone into anything, it can be ignored, it can be disabled even. It is just another drop-down box for those that would like to use it. 1 != 2 02:16, 17 October 2007 (UTC)Reply
It's not just "instructions", the script (code) has to be changed first. To be honest, the script could also have some other requested/suggested features, such as the ability to append the original reason ("content was ...") and making the input field larger. Also a good idea is to add "what's this? link so admins don't have to wonder "where did this new feature come from?" ∴ AlexSm 04:05, 17 October 2007 (UTC)Reply
I agree with Nihiltres that unless you can easily override the available menu options to tailor the list to an admin's preferences, I don't think it would good idea to include the script. I have to admit that I wrote my own similar code that has a lot shorter list than CSD AutoReason as it is tailored to the deletions that I commonly do. -- Gogo Dodo 06:10, 17 October 2007 (UTC)Reply

window.disableSysopJS = true edit

It needs to be made very clear to all admins that they can disable the effect of sysop.js - my browser has been crashing for the past week when I delete or undelete pages, and I think the change to this page is the reason why. Neil  10:04, 19 October 2007 (UTC)Reply

Javascript error edit

For the past few days I've been receiving javascript errors on the undelete page. Someone pointed me the way of this page. I wrapped the code in a try{} catch(e){} thing and that seems to have stopped the javascript error, at least. But it doesn't fix whatever problem there is in the code itself. Please next time when making changes to js pages, test them in all major browsers (Internet Explorer, Opera, Firefox, Colloquy...) or ask people who have the browsers to do it for you. - Mark 13:54, 25 October 2007 (UTC)Reply

Change addEventListener() back to onclick as it was in the first version of the script. addHandler() from http://en.wikipedia.org/skins-1.5/common/wikibits.js could also be used ∴ AlexSm 14:38, 25 October 2007 (UTC)Reply

Avoiding libel in deletion summaries edit

While we're debating the inclusion of ^demon's CSD AutoReason script, how about including User:Ilmari Karonen/cleandelsummary.js? It replaces autogenerated deletion summaries for articles tagged as attack pages with a generic summary that avoids inadvertently recording any of the libelous or offensive content in the deletion log. —Ilmari Karonen (talk) 02:08, 8 November 2007 (UTC)Reply

Since no-one seems to have any objection, I've included the code. Please let me know if it causes any problems. (Or just revert if I'm not immediately available to fix it.) —Ilmari Karonen (talk) 02:02, 25 November 2007 (UTC)Reply
Ps. You can test the effect of the script by clearing your cache, going to User:Ilmari Karonen/cleandelsummary-test and clicking the delete tab. (Please don't actually delete that page, or at least undelete it if you do.) —Ilmari Karonen (talk) 02:07, 25 November 2007 (UTC)Reply
Ooh... I wish it would do that for all db-categories! EdokterTalk 14:58, 25 November 2007 (UTC)Reply

Deletion dropdown list edit

Changed section title from «Just added» ∴ AlexSm 01:03, 30 December 2007 (UTC)Reply

What was that which was just added? 1 != 2 22:54, 29 December 2007 (UTC)Reply

A script that present another dropdown box with CSD reasons. I gues we can do away with MediaWiki:Deletereason-dropdown now... EdokterTalk 23:36, 29 December 2007 (UTC)Reply
Too bad it still doesn't work with images. Garion96 (talk) 00:38, 30 December 2007 (UTC)Reply
Right. Instead of replacing the existing list of summaries (making it less convenient in some way), the author of the script could implement a missing dropdown box for images (until mediazilla:12214 is fixed) ∴ AlexSm 01:03, 30 December 2007 (UTC)Reply
It seems that when Ryan Postlethwaite replaced my clean G10 deletion summary script with this code (which seems to be some variant of ^demon's CSD AutoReason script), he left in a header describing the former script and listing me as its maintainer. Since I have no desire to have anything to do with the current code, I've updated the description and removed my name.
In any case, I'd be interested in hearing what, if anything, the current code adds over the similar builtin feature provided by MediaWiki:Deletereason-dropdown. I'd also like to ask for opinions on restoring the former code, which automatically sanitized deletion summaries for articles tagged as attack pages to avoid including offensive or libelous material in the summary. I still think that code was useful, and would like to restore it, but I'd like to hear Ryan's opinion first since he's the one who removed it. —Ilmari Karonen (talk) 08:25, 6 January 2008 (UTC)Reply
Most probably should have posted here, but I posted to AN/I when I first made the edit to this page to make as many people aware as possible. I made the change for two reasons. Most importantly, when using the old version of the page, when you selected a deletion reason, the contents of the page stayed in the log reason and had to be manually deleted, many admins were not doing this and it's resulted in some quite serious attacks being kept in the logs - the reason why I finally made the change was because an administrator had been subject to quite a serious legal threat because he'd left an attack of a rather prominent profesor in the deletion log of his bio when using this tool. The version I changed it to automatically removes the content of the page when the deletion reason is selected, meaning this major concern is no longer a problem. Secondally, we delete pages for all sorts of reasons, and this version has just about every eventuality, yet is still easy to user and isn't over-convoluted. Hope that explains why, and helps to understand that because of the serious log entry concern (especially with attack pages) why going back to the original would probably be a bad idea. Ryan Postlethwaite 18:25, 6 January 2008 (UTC)Reply
All of this this could be achieved without totally replacing MediaWiki:Deletereason-dropdownAlexSm 18:39, 6 January 2008 (UTC)Reply
True, but I did it as soon as I became aware of some very serious concerns - it wasn't a case of "let's wait until someone fixes the current version." Many, many users have used the tool I added prior to MediaWiki:Deletereason-dropdown coming into play, and everyone was very satisfied with it. It would probably have been preferable to a wider audience than the original version. Ryan Postlethwaite 18:47, 6 January 2008 (UTC)Reply
I'd still like to know why you removed my G10-autofixer script while adding your dropdown code. It had nothing to do with the dropdown box, and I would've thought that, if you were concerned about libel in deletion summaries, you would've wanted to keep it since it helps to avoid that possibility in many cases. —Ilmari Karonen (talk) 20:13, 6 January 2008 (UTC)Reply
Just G10? We should have that for all the reasons - we generally don't want any contents of pages in deletions logs. The script I put in automatically removes all the contents upon picking a deletion reason so it has superceeded any autofixer that was there. Ryan Postlethwaite 22:56, 6 January 2008 (UTC)Reply
Really? When I click on "Random article" and then "delete", the text I see prefilled in the summary field is "content was: '{{otherpeople|William Moore}} '''William Moore''' (fl. c.1806–1823<ref>[http://www.oxforddnb.com/view/article/58180 W. Johnson, ‘Moore, William (fl. c.1806–1823)’, ''Oxford Dictionary of National Biography'', Oxford University Pr...'". Looks like the content of the page to me. The same happens on my fake attack page, where the libel remover should kick in, without any user intervention — except, of course, for the fact that it's no longer included here. Perhaps you didn't quite understand what the script you removed was doing? —Ilmari Karonen (talk) 00:05, 7 January 2008 (UTC)Reply
I'm no coding expert, I just added a script that I knew would work better than the original when I realised the major concerns with it - so yeah, I obviously didn't quite know what I was removing. Could you add that part back please? Ryan Postlethwaite 00:10, 7 January 2008 (UTC)Reply
As Ryan Postlethwaite said, after the change you did not had to remove by hand the contents of the page in the log reason anymore. That was one major improvement. As long as that stays, I don't care which version is used. Garion96 (talk) 22:51, 6 January 2008 (UTC)Reply
Being non-admin, I fail to see this as an improvement. And I guess some other people too. Especially since you also delete "the only author was...". On the other hand, buttons to quickly delete the content and then add it back would be fine ∴ AlexSm 00:23, 7 January 2008 (UTC)Reply
I've already stated the major problem with the original, it opened us up to serious legal problems. Even if this was fixed, I still feel the new script is better as it gives just about all deletion reasons, and they're easily accessible. Ryan Postlethwaite 00:33, 7 January 2008 (UTC)Reply

MediaWiki talk:Sysop.js/Admin opinion edit

Please see the above link, as I have requested greater input from the wider community input into discussion on which version of the automated deletion reason tool to use. Ryan Postlethwaite 00:56, 7 January 2008 (UTC)Reply

Wikipedia:Administrators' noticeboard#Delete reason dropdown scriptRandom832 17:27, 4 February 2008 (UTC)Reply

Image deletion reasons edit

I get the image reasons on every other type of page, however the list doesn't appear on image pages. Is this a quirk of my set up, or are other admins experiencing this? Addhoc (talk) 01:24, 7 January 2008 (UTC)Reply

It's all admin, I think it's a bug - it would be great if there was a code available for images (note - this is the same for both scripts). Ryan Postlethwaite 01:27, 7 January 2008 (UTC)Reply
mediazilla:12214, as I pointed above. Easy to fix with some JS code ∴ AlexSm 01:39, 7 January 2008 (UTC)Reply
Thanks for explaining. Addhoc (talk) 02:08, 7 January 2008 (UTC)Reply

A small change edit

I made this change (now self-reverted) to the interface to highlight that user pages, and not just talk pages, in CAT:TEMP are deleted, but when I went into the delete screen, my edit didn't do anything to the drop-down reasons. Is there something I missed? Acalamari 23:16, 6 February 2008 (UTC)Reply

Did you purge your cache? Ryan Postlethwaite 23:24, 6 February 2008 (UTC)Reply
I've readded you edit - purge your cache and try again. Ryan Postlethwaite 23:25, 6 February 2008 (UTC)Reply
It works, and it'll help when clearing CAT:TEMP. Thanks Ryan! Acalamari 23:49, 6 February 2008 (UTC)Reply

CSD template rewrite edit

There is currently a discussion going on at WT:CSD which will probably result in the CSD templates being rewritten, with one side-effect being the removal of the horrible {{hidden-delete-reason}} template (for an explanation of why it's so horrible, take a look at this version of {{db-t3}}). I'm doing my best to keep the <span id="delete-reason"></span> tags in place, but I'm kind of groping in the dark as to what this script or the other deletion-reason-preload scripts are actually looking for. Any pearls of wisdom from someone who knows what those spans need to say, if anything, would be greatly appreciated, either here or on my talk. Happymelon 15:40, 1 March 2008 (UTC)Reply

Avoiding [move=autoconfirmed] in logs edit

Suggestion: the code currently in testwiki:MediaWiki:Sysop.js avoids automatic "move=autoconfirmed" addition (which makes no sense) when semi-protecting pages. Then Special:Log/protect would look better and easier to understand: it would say [edit=autoconfirmed] instead of [edit=autoconfirmed:move=autoconfirmed]AlexSm 22:40, 20 June 2008 (UTC)Reply

I think it's very convenient to see both protection statuses in one line. Otherwise I would still have to go to the page's log to see if it is move-protected. EdokterTalk 23:05, 20 June 2008 (UTC)Reply
As far as I know, this is not an issue: when you set edit protection, you also have to set some move protection level (0, 1 or 2), there is no option to "silently leave move protection as-is". In other words, [edit=autoconfirmed] in logs always means "no move protection". —AlexSm 01:02, 21 June 2008 (UTC)Reply
More to the point, you can't move a page if you can't edit it. So the only situation where it makes sense to explicitly set or show the move protection level is when it's higher than the edit protection level. However, while the JS trick on testwiki is indeed clever, I think this would be best implemented directly in MediaWiki. —Ilmari Karonen (talk) 11:32, 21 June 2008 (UTC)Reply

Where is the documentation? edit

Does anyone know where this page is documented? What calls it, how is it activated? I checked the banner at the top of this page which says to go to mw:Manual:Interface/Sysop.js, but there's nothing there. --Elonka 15:51, 18 December 2008 (UTC)Reply

The script is included from MediaWiki:Common.js (a few lines near the top) if you're a sysop. It checks if the javascript variable 'wgUserGroups' (see the html source) contains 'sysop', or if any other javascript contains 'disableSysopJS = true'. -- zzuuzz (talk) 16:23, 18 December 2008 (UTC)Reply
Thanks. So this javascript is automatically activated by default for anyone with a sysop bit, and they don't need to do anything specific to their own monobook.js pages, correct? --Elonka 16:51, 18 December 2008 (UTC)Reply
Yes, you only need to add something to you monobook.js if you want to disable it. -- zzuuzz (talk) 16:57, 18 December 2008 (UTC)Reply

Sensitive IP checker is out of date edit

The Toolserver has been permanently soft-blocked for some time now (see Special:BlockList/91.198.174.192/27), since both our policy and Toolserver policy require that bots must be logged in to edit. I don't know if anyone cares enough to remove it from the list here, but since I noticed I thought I'd mention it. Anomie 23:14, 2 February 2011 (UTC)Reply

Minor addition for Checkuser edit

Would anyone mind me adding a small script to enforce summaries for the CheckUser interface:

/** For checkusers *****************************************
 *
 *  Description: Force checkusers to fill in the reason.
 *  Note [[:bugzilla:27078]], [[:bugzilla:18613]]
 */
if (mw.config.get("wgCanonicalNamespace")==="Special" && mw.config.get("wgCanonicalSpecialPageName")==="CheckUser") jQuery(function($){
	$("#checkusersubmit").click(function(event){
		if ($.trim($("#checkreason").val()).length > 0) return;
		alert("Please enter a reason");
		event.preventDefault();
	});
});

Intended as a quick and unobtrusive fix to make sure filling in a reason is not forgotten. While there is an option in the extension to make sure of that, and it was turned on with bugzilla:27078, it's not working yet due to some bug. The script should be removed again once bugzilla:18613 is resolved and live, and can be moved to MediaWiki:Group-checkuser.js if r82285 & follow-ups go live before that.
Any objections? Amalthea 07:50, 20 June 2011 (UTC)Reply

 Y Added. Amalthea 10:12, 21 June 2011 (UTC)Reply
Is this required now that 1.18 is here? –xenotalk 19:01, 12 October 2011 (UTC)Reply
I've already removed it back in July. :) Amalthea 19:26, 12 October 2011 (UTC)Reply
Sneaky ;p –xenotalk 19:32, 12 October 2011 (UTC)Reply

Special:Undelete was fixed on MW code edit

Hi!

I just wanted to notice that since rev:90359/rev:90587 MediaWiki has a script which "creates a button to invert checkboxes on Special:Undelete", so this part of MediaWiki:Sysop.js will be obsolete when the code is deployed to Wikipedia. Helder 12:27, 30 June 2011 (UTC)Reply

 Y Done The new code is in core and our old copy was removed by Edokter. Helder 17:41, 5 October 2011 (UTC)Reply
Is this working as intended? Now there is no invert button at all? See Wikipedia:Village pump (technical)#Invert selection button missing. –xenotalk 18:59, 12 October 2011 (UTC)Reply
Resolved, see there. Amalthea 19:30, 12 October 2011 (UTC)Reply

Blockip → Block edit

MW 1.18 changed special page name to "Block" so "Sensitive IP checker" supposedly doesn't work at the moment. P.S. Could also remove absolute URLs and use jQuery. — AlexSm 17:25, 13 October 2011 (UTC)Reply

Fixed the script. Didn't do anything about the URLs or jQuery. Anomie 18:15, 13 October 2011 (UTC)Reply

Conversion to gadgets edit

MediaWiki 1.18 introduced the concept of group-specific scripts, like MediaWiki:Group-sysop.css. It would seem logical to move this script to MediaWiki:Group-sysop.js. That saves having to load it from Common.js. But there is a better way.

Gadgets have the ability to be enabled based on user rights. This has more advantages; beside not having to load it from Common.js, functionality can be split up into multiple gadgets. That way, each admin can decide which one to enable or disable, and do so without have to put kludges like disableSysopJS = true into their personal JS. All gadgets would be enabled by default. Edokter (talk) — 13:51, 19 January 2012 (UTC)Reply

Looks like an excellent idea to me. One reason I don't want to be an admin is that I don't want my editing interface cluttered. Being able to turn specific parts on and off effortlessly would completely change this. Maybe it could also reduce the number of requests to bureaucrats to temporarily reduce rights if all it takes to go on a sort of admin break is a few clicks under preferences. Hans Adler 14:03, 19 January 2012 (UTC)Reply
As long as they are enabled by default, this looks like a good idea. -- Luk talk 14:04, 19 January 2012 (UTC)Reply
I'm not necessarily against it becoming a gadget, but this doesn't control the sysop interface at all really. The scripts here handles the highlighting of sensitive IPs (only if you're already on the blocking page, and I don't know why we'd want this turned off) and pre-filling of the delete reason for CSD (where you already need to be on the delete page). I'm genuinely trying to this why someone would want these specific features disabled while retaining everything else, and I can't. Is it a good idea to make it easier to turn off sensitive IP highlighting? Ale_Jrbtalk 17:33, 19 January 2012 (UTC)Reply
I support the idea of moving this into a gadget. I think it is good to have the option to disable any site script while testing and looking for the cause of eventual bugs. Besides, maybe this script is useful for other wikis as well, and could be loaded by gadget manager from a central wiki in the future Helder 20:30, 19 January 2012 (UTC)Reply

Very well. I'll start testing on the beta installation. There are only two functions: AutoDropdown for deleting pages, and Sensitive IP Checker. The latter one could be considered mandatory, in which case moving that to MediaWiki:Group-sysop.js would be more appropriate, so it cannot be turned off. Thoughts? Edokter (talk) — 20:41, 19 January 2012 (UTC)Reply

Support. ~ ⇒TomTomN00 @ 23:45, 17 March 2012 (UTC)Reply
  Done Moved MediaWiki:Sysop.jsMediaWiki:Group-sysop.js and removed hack in MediaWiki:Common.js. I've kept the ability to disable with disableSysopJS for now. Krinkle (talk) 20:21, 27 May 2012 (UTC)Reply

IP test edit

What do you think about changing

/\b(?:(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\.){3}(?:25[0-5]|2[0-4][0-9]|[01]?[0-9][0-9]?)\b/.test(ip)

to

mw.util.isIPv4Address(ip) || mw.util.isIPv6Address(ip)

? Helder 00:36, 28 May 2012 (UTC)Reply

Why does it need to be repeated? Happymelon 11:14, 28 May 2012 (UTC)Reply
Oh, sorry (copy/paste fail...) the second one should not be isIPv4Address, but isIPv6Address. Helder 11:24, 28 May 2012 (UTC)Reply
This is pure gobbledygook. Happy-melon, can you deal with this?? — Martin (MSGJ · talk) 05:42, 2 June 2012 (UTC)Reply
JavaScript isn't really my speciality, I'm afraid. Happymelon 08:45, 2 June 2012 (UTC)Reply
  1. The change would require inclusion of the 'mediawiki.util' module
  2. It's a bit pointless as long as all IP regexes that are then tested are IPv4
  3. The test doesn't work if you're blocking a range (Special:Block/63.162.143.21 vs. Special:Block/63.162.143.0/24)
  4. It's a rather ugly test to begin with, it would be way more maintainable to just be able and list the problematic CIDR ranges
So I'd rather make more fundamental changes. I already have some js code to test two IPv4 ranges against each other, and I have to extend that to IPv6 during the next days anyway ... Amalthea 09:32, 2 June 2012 (UTC)Reply
Disabled edit request for now. Suggest Helder works with Amalthea on this. — Martin (MSGJ · talk) 07:17, 4 June 2012 (UTC)Reply

Protected edit request on 11 July 2014 edit

Hello! Could someone update the code of this page to not use deprecated things? Helder.wiki 00:02, 12 July 2014 (UTC)Reply

  Done — Martin (MSGJ · talk) 11:51, 24 July 2014 (UTC)Reply