View Issue Details
| ID | Project | Category | View Status | Date Submitted | Last Update |
|---|---|---|---|---|---|
| 0002662 | unreal | ircd | public | 2005-10-17 12:29 | 2007-04-27 04:51 |
| Reporter | Jinn | Assigned To | |||
| Priority | normal | Severity | feature | Reproducibility | N/A |
| Status | closed | Resolution | wont fix | ||
| Product Version | 3.2.3 | ||||
| Summary | 0002662: make channel admin\owner more usefull | ||||
| Description | +q should be set on a user when they first create a channel instead of just +o. Else you need can_override\services to get it and if you can override or registered your channel then the mode is pretty useless for you anyway. Also some things should only be changable by the owner, eg. topic, (maybe make a owner setable mode to change the op level to change the topic?) and modes Q,f,z. As for +a, all i see it atm is for protection from kicks. +o should be +a\q only (if halfops\admins cant give other people halfop\admin why should ops be able to give other people op?) Modes l,I,e,G and kicking of +o should be admin only (again if halfops\admins cant kick each other why can ops?) | ||||
| 3rd party modules | |||||
|
|
yeah, pretty good ideas.. That +q is almost useless. |
|
|
Setting +o on someone is by the RFC IIRC, so that cannot be changed. Unreal expects there to be services to give people whatever modes they need. Making +o users unable to +o another user again might be against the RFC. There is no reason to restrict that, as a channel operator has near full control over the channel. +a is just for protection, and is a higher op level, and they don't have any extra mode setting abilities. +q is channel founder, and has absolute control over the channel, including being able to set additional modes. |
|
|
the irc rfc only says the creator of a new channel must be given +o, it does not say anything about other modes (because 12 years ago only had +o\v) so +oq could be given at the creation of a new channel. services are ulined, so they could give somebody op status (and most services bots give themselfs +a anyway) +q can only set +u and +L (both which are pretty useless) but a channel op can set modes and change the topic that only the owner or admins should be able to change. Having a whole channel status just for kick protection is rather useless, especially since without services\operoverride you cannot get +a so services will be able to protect you anyway, so it should be either removed or given special abilities that regular ops cannot use. |
|
|
I might just do a quick workover on my joindeop mod to do this, as I've wanted it for my testnet too - but it's not been done, so. :P |
|
|
And to add something, +L is a whole lot more important than the topic. Imagine you own a channel, a large one - one of your ops gets a bit shitty and links it over to their channel and informs them that it's now the 'new' one - well, you're sunk :p |
|
|
which is why its already +q only :p any comments on this? |
|
|
Halfops can't do anything to other halfops because they're supposed to be limited. Admins can't do anything to other admins because they're "protected users". Not only can they not kick each other, they can't devoice each other, they can't dehalfop each other, they can't deop each other, they can't deadmin each other. They can kick/dewhatever themselves, but not other admins. Otherwise the protection isn't as useful. Ops aren't "protected users". They just can't be mucked with by halfops because halfops are lower :P . If you want X billion things only the owner can do, JUST USE SERVICES (hint: /cs set #channel mlock +whatever-whatever and /cs set #channel topiclock on + /cs access #channel disable topic). Most services let you register channels which then gives the registerer +qo on join. IRCds aren't supposed to do the things services are designed for. For example, yes, Q might be useless unless it's mlocked or something, but it's not as useless if you have a lot of halfops (hint: they can't muck with Q). You could have a policy that the channel is +Q until a kick needs to be made. Then your %s are limited to just modes. If you want certain op-related things enforced without services, use an eggdrop. Though, if you're worried about abusive chanops you have two options: one, run about 60 or so eggdrops (= maximum number needed to be safe from massdeops which I get from 12 deops per mode * about 5 or so modes before fakelag kicks in) or two, think more carefully about who you give +o to! (the preferred method, see comment on previous option for why (60 eggdrops is a lot of RAM if you run 'em on the same box, though energymech might be able to do it? not same box means you have that many shell providers and that many shell bills and... I hope you have some serious money even if you pull off 3 or 4 eggdrops per shell ;P )) |
| Date Modified | Username | Field | Change |
|---|---|---|---|
| 2005-10-17 12:29 | Jinn | New Issue | |
| 2005-10-17 13:39 | pinstrate | Note Added: 0010594 | |
| 2005-10-17 13:40 | Stealth | Note Added: 0010595 | |
| 2005-10-17 13:53 | Jinn | Note Added: 0010598 | |
| 2005-10-18 01:30 | w00t | Note Added: 0010600 | |
| 2005-10-19 18:56 | w00t | Note Added: 0010604 | |
| 2005-10-19 18:59 | Jinn | Note Added: 0010605 | |
| 2005-10-19 23:07 | aquanight | Note Added: 0010606 | |
| 2005-10-19 23:08 | aquanight | Note Edited: 0010606 | |
| 2007-04-27 04:51 |
|
Status | new => closed |
| 2007-04-27 04:51 |
|
Resolution | open => wont fix |
