View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0003030 | unreal | ircd | public | 2006-08-20 06:09 | 2006-12-12 10:03 |
| Reporter | vonitsanet | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | always |
| Status | closed | Resolution | no change required | ||
| Product Version | 3.2.5 | ||||
| Summary | 0003030: Allow +Q and/or -Q only from channel owner | ||||
| Description | It sounds more logical to me if only channel owner can +Q or -Q a channel. This is a log from #unreal-support: <+Muisje> vonitsanet <+Muisje> +Q can be easily overrided <+Muisje> eg[mircscript]: /kbq /ban $$1 2 | /mode $chan -Q | /kick $chan $$1 Permanent ban. Reason: $2- | /mode $chan +Q <+vonitsanet> so if only the channel owner (~) is allowed for this mode <+vonitsanet> ? <+vonitsanet> this is my point <+Muisje> to set / remove the moe <+Muisje> mode* <+vonitsanet> yep <+Muisje> you need channel op or higher <+vonitsanet> to kick u have to be a channel oper <+vonitsanet> anyway:P <+Muisje> to kick you need to be channel halfop <+Muisje> or higher <+vonitsanet> so it works fine only with halfs <+vonitsanet> :S | ||||
| 3rd party modules | |||||
| has duplicate | 0003364 | closed | +Q settability |
|
|
I think you are right and this mode should be given to higher ops. But i don't suggest ~ (+q / founder), i suggest & (+a / channel admin). Edit for aquanight: I already stated on IRC to vonitsanet that +Q mlock won't stop a bit script from kicking before services gets the chance to readd it. |
|
|
Not really needed: - If you have services, you can just mlock it. Otherwise you can use it to keep halfops in check (no way for them to kick except through services if +Q is set). - If you don't have services, no one would be owner or admin, and the mode wouldn't even be remotely usable. |
|
|
just in theory with +Q mlocked (i dont know:/): //mode #channel -Q | /kick #channel user1 |
|
|
It certainly is possible to race the mlock, as ref'd in bug 2992. My current solution in my services is that if +Q is mlocked, to kill the kicker, invite and svsjoin the kickee back, and unban them as well. |
|
|
also, as ref'd in 2992, this currently can cause a desync. That will be fixed for 3.2.6 and 3.3 |
|
|
I never liked this mode, and I think I can speak for the rest of the team as well. We had a poll several years ago asking if it should be removed, obviously almost everyone answered "NO!" by automatism, not because they actually used it. The question came up when +Q was actually useful, after all.. what use is it being a chanop when you can't kick? The answer was that it could be useful when eggdrops (like w/+revenge) or other revenge scripts went nuts, to set the channel +Q until they calm down. That's the best reason I've heard yet, and I can't say it's that good :P. So in that case, making +Q chanadmin and higher wouldn't be too useful. Now, when you make +Q settable for chanadmin and higher.. What use does it give? Ignoring the eggdrop/revenge thing, what's the argument for doing this? What use are chanops when they can't kick? Not to mention they could set - for example +f with low limits like 1 message per 15 seconds allowed (+f [1t]:15) to indirectly still being able to kick people. Oh and actually they do still have some power (yeah now I'm contradicting myself), they can still -vvvv and -ooo and set +m or +b .., etc... I guess that brings us back to... what's the purpose and usefulness of this mode? And what are the (access) requirements for the mode to make it 'ok' to do that task. |
|
|
In return to Syzop: What use is it being a chanop when you can't kick? You can still do the normal stuff like banning someone and make him silent. I do like this mode and i think it is usefull. +Q is in eyes towards me (and possibly many others), to allow giving access and the rights belonging to the access, without having to watch kicks... This mode could also be usefull as an anti flood option, eg when servers are being flooded you could make services / bots to set the mode in any channel. In short a few good reasons summed up for the +Q mode: * Antiflood (Like eggdrops/revenge kicks) * Limitation (No explanation mandatory i assume) * Flexibility (Letting the Chanadmins/Owners to decide.) * Functionally (Stop people from freaking out and start a kick fight, this way they will calm down and yes, if you have such people as chanops, you might want to reconsider but still... * Another Function (To silence people and not have to watch kicks etc.) * Bandwidth saving (Well, since you can't kick, It'll save ya some bytes ;) * Fun (To temp piss of your chanops :P) We don't ask for +Q to limit all chanop powers, just kick. And i think a Chanadmin or Founder should be the only one to set it. If thise note isn't convincing well, then delete it from core and release a module for it. That's the best way to do it and i would love to see Unreal becoming more modular, so i really got my own choice what to load and what not. Cause now i'm getting forced with some stuff i don't want available for my opers, EG: Oper abusive.. , Not monitored.. stuff like that. {PEACE}. |
|
|
I don't just delete features because I personally don't like them. Otherwise it would have been removed 3 years ago. Almost all channel modes will be modulized in Unreal3.3*, this process is already ongoing. As for the arguments you made for +Q.. I can't say they convinced me. You listed many points but they actually come down to 2 or so. * Antiflood (Like eggdrops/revenge kicks) Right. * Limitation (No explanation mandatory i assume) Well, I disagree about the usefulness. * Flexibility (Letting the Chanadmins/Owners to decide.) Uhm.. Not exactly an argument for having this mode.. Any mode allows "flexibility" * Functionally (Stop people from freaking out and start a kick fight, this way they will calm down and yes, if you have such people as chanops, you might want to reconsider but still... Uhm, every chanmode provides some "functionality". But indeed, you are already mentioning my point.. if you have such chanops other measures should be taken. * Another Function (To silence people and not have to watch kicks etc.) Uh-huh.. Oh ok.. You mean setting -v if needed, and then +b'ing, to make someone shut up. * Bandwidth saving (Well, since you can't kick, It'll save ya some bytes ;) Not exactly a good argument, huh :P. * Fun (To temp piss of your chanops :P) Guess I don't have to say anything about this either :P So ehm, basically, in what situation did you mention it would be useful? (rephrased:) "giving people chanop rights without giving them kick power" Well yes, but why... Well... We already went through this and I didn't get a good reason yet. Perhaps it looked like I wanted to rip out +Q, but what I actually wanted to say is... when is this mode useful, and thus what access requirements would be proper. Let me give you an example: for the eggdrop kickfight argument, it would be very useful to have +Q settable by +o (like now), so any oper can stop the kickfight (this has actually been brought up by someone else). On the other hand, if you seriously find +Q useful to prevent chanops from kicking; like as some kind of "policy", then +a is more useful. Hence, the purpose of the mode is a key question in deciding which access requirements it should have. |
|
|
Ow yeah i forgot to mention that even while it is stupid to have such chanops, sometimes normal chanops start fighting eachother and trying to kickban and get back by services. The +Q would be great. But ok, maybe my reasons lack a bit of a professional explanation, i did hope you would agree with me at more then 2 of them ;) Peace, out. Btw, this topic basically goe's about +Q being evaded. Maybe you are right and it should remain as chanop, But maybe add a 2 second delay before kicking is allowed so that it won't override cs mlock? Would be great if services lag doesn't cause people to get around :) If that can be done, ignore what i said. (Btw in the case kick's can be delayed by 2 or something, well you know it better than me. :p) |
|
|
This is my take on it, and how I have implemented it now, tho I should say, it was kronos' idea before me, I just fleshed it out implemented it (as well as the ircd patch/bugfix (0002992) to make it work). Goes like this (all predicated on chmode +Q being mode-locked) a) if someone races the mode-lock, the kicker get a KILL, and the target is svsjoined back b) if you use the Services kick command (CS KICK or !KICK), and the target has channel-access (of any kind) the kick is refused. If the user does _not_ have access, it is allowed. This then prevents chanop wars, but still allows the channel to be moderated. Misbehaving ops, we chalk up to being the founder's problem. Oh, and as to access requirements, I'd be ok if you made this U:line only. Makes more sense. |
|
|
Plenty of people on our network use +Q, around 15% of channels have it mlocked. The reason for this is stupid, of course. People like to op all of their friends which causes endless op wars. But still, removing it would cause a lot of complaints. As for this bug, some possibly better solutions come to mind; either add a 5 second delay between when +Q is removed to when kicks are allowed, to give services a chance to enforce a modelock; or if you want to get rid of +Q, have a +f setting that limited the rate of kicking per op. |
|
|
the 5 second idea sounds ok, configureable my only objection is some few hundred bots or so flooding and i have to wait 5 secs or wotever to lift Q to kick em out coz they wont leave |
|
|
the X second delay is unfortunately 'too hackish' |
|
|
As for the mlock race condition, I've tossed up an idea at 0003055 (please reply there about it, not here ;p). |
|
|
Removing the mode would be stupid (and would also cause a lot of problems), as its very useful, I do however like the idea of making it channel owner (+q) only. |
|
|
*bump* ;P |
|
|
First of all, I wouldn't be changing this in 3.2* anyway, so this is all about 3.3*: I think it was concluded that the people actually using this mode use it against masskick scripts/eggies going out of control, hence wanting +o access requirement (not +a). As for the people that considered using this, it would be usually to make it so people would be chanops but without kick rights (Hrm ;p), such as only allowing /CS KICK to be used (a possible good point). In that case the linked idea (0003055) would be a good solution in the future. |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2006-08-20 06:09 | vonitsanet | New Issue | |
| 2006-08-20 06:15 | Muisje | Note Added: 0012192 | |
| 2006-08-20 14:06 | aquanight | Note Added: 0012195 | |
| 2006-08-20 14:14 | vonitsanet | Note Added: 0012196 | |
| 2006-08-20 19:11 | Muisje | Note Edited: 0012192 | |
| 2006-08-22 02:09 | tabrisnet | Note Added: 0012201 | |
| 2006-08-22 02:09 | tabrisnet | Note Added: 0012202 | |
| 2006-09-01 05:12 | syzop | Note Added: 0012275 | |
| 2006-09-01 10:44 | Muisje | Note Added: 0012278 | |
| 2006-09-01 11:23 | syzop | Note Added: 0012279 | |
| 2006-09-01 11:50 | Muisje | Note Added: 0012280 | |
| 2006-09-01 11:52 | Muisje | Note Edited: 0012280 | |
| 2006-09-01 13:01 | tabrisnet | Note Added: 0012281 | |
| 2006-09-01 13:03 | tabrisnet | Note Edited: 0012281 | |
| 2006-09-01 14:31 | kronos | Note Added: 0012283 | |
| 2006-09-01 14:32 | tabrisnet | Note Edited: 0012281 | |
| 2006-09-05 06:11 | White_Magic | Note Added: 0012315 | |
| 2006-09-05 06:15 | syzop | Note Added: 0012316 | |
| 2006-09-05 06:44 | syzop | Note Added: 0012317 | |
| 2006-09-07 21:34 | djGrrr | Note Added: 0012350 | |
| 2006-12-11 06:57 | vonitsanet | Note Added: 0012813 | |
| 2006-12-12 10:03 | syzop | Status | new => closed |
| 2006-12-12 10:03 | syzop | Note Added: 0012816 | |
| 2006-12-12 10:03 | syzop | Resolution | open => no change required |
| 2007-05-28 16:22 | aquanight | Relationship added | has duplicate 0003364 |
