Question

Jump to navigation Jump to search

What are you trying to do? Want me to help?

Also, when you create a new usergroup, it should be lowercase (i.e. moderator and tech not Moderator and Tech), you should then create pretty names for it in function setupCustomNames(), just take a look at how I did it for Ninjas and Irrational numbers

-- Nx / talk06:20, 25 May 2011

Allright I will make adjustments to the tech and mods. I was just playing with the blockip hook to see how hard it would be to try and make an extension that prevented sysops from changing a mods block. At this point I am just poking at blockip trying to figure out the block object. If you have suggestions help would be cool.

Tmtoulouse (talk)06:25, 25 May 2011

Hm, that's complicated, the easiest way would be to check the blocker's user rights, but if the blocker is demoted sysops will no longer be prevented from changing the block. I'll see if I can find a better solution.

Btw, I've written an extension before that can limit the length of a block a certain user group can give out (e.g. sysops would only be able to block for 30 minutes max, and wouldn't be able to block without allowing user talk page editing). It might be a good idea to install that if we're keeping the sysops can make sysops policy.

-- Nx / talk06:32, 25 May 2011

Yah I ran into that extension's code while googling around for the block ip hook. Was thinking about it.

My idea was to get the user name being blocked and use that to look up the block log and if there was a block in place on that user check who the block as by. If the old block was by a moderator then the block could only be changed by a user in the mod group.

Tmtoulouse (talk)06:42, 25 May 2011

If I understand correctly, that would suffer from the same problem.

-- Nx / talk06:46, 25 May 2011

I guess could always add a check mark box option for mods to "prevent unblocking" that gets saved with the block.

Tmtoulouse (talk)06:50, 25 May 2011

That's probably a good idea, otherwise, mods couldn't engage in joke blocks, because then people couldn't unblock themselves.

Eira OMTG! The Goat be Praised.06:51, 25 May 2011
 

Yeah, but that would probably be messy, it would require changing the database schema and hacking MW

-- Nx / talk06:51, 25 May 2011

Maybe add a "mod block" thing to the vandal brake?

Tmtoulouse (talk)06:55, 25 May 2011

Suggestion - why not open an ER in the Mediawiki bug tracker? I think what you are talking about here is an interesting use case, which may be of interest beyond just RW. Even if the Mediawiki developers don't do anything, if you make a change you could always work on getting it upstream (then you won't have to maintain it anymore...)

(((Zack Martin)))07:18, 25 May 2011
 

Ok, here's an idea: If the blocked user's user page is protected at the mod level, their block can only be changed by a mod. It's a hack, but it's pretty easy to implement.

-- Nx / talk07:29, 25 May 2011

Dammit, there's no hook for unblocking, so I can prevent changing blocks, but not unblocking. I've got to go now, I'll get back to this later.

-- Nx / talk08:58, 25 May 2011

Well shit, I was hoping unblock was treated like a change block....

Tmtoulouse (talk)18:13, 25 May 2011
Edited by author.
Last edit: 20:20, 25 May 2011

Editing MW so that unblock = change block to 0 would solve this, I guess, but may be way too much hassle.

NDSP20:13, 25 May 2011

We don't want to edit MW, maintaining a patch is too much work.

-- Nx / talk20:19, 25 May 2011

Do it properly and you can upstream your patch.

(((Zack Martin)))20:50, 25 May 2011

Been there, done that, getting a simple patch for an actual bug upstreamed takes forever, can't be bothered.

-- Nx / talk04:25, 26 May 2011