View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0000917||unreal||ircd||public||2003-04-24 23:51||2004-02-05 22:58|
|Summary||0000917: Disallow users to deop/deown/.. services|
|Description||On-channel services are allowed to be deopped. Can you fix this in the next beta pls?|
|Steps To Reproduce||/mode #chan -o SomeService|
|Additional Information||I'm using this as a bit of a hack in the mean time:|
if (IsServices(who) && (!IsServer(sptr)))
":%s %s %s :*** Cannot kick %s from channel %s, it is a network service",
me.name, IsWebTV(sptr) ? "PRIVMSG" : "NOTICE", sptr->name,
Wow, C code looks ugly in these text boxes :D
|Tags||No tags attached.|
|3rd party modules|
||errrr... did i paste the wrong bit of code :/|
I did ... sorry
&& (what == MODE_DEL))
":%s %s %s :*** You cannot %s %s in %s, it is a network service.",
me.name, IsWebTV(cptr) ? "PRIVMSG" : "NOTICE", cptr->name, xxx,
... as before
and get the CVS version
||maybe i'm blind, but huh? my query had nothing to do with /whois... and it hasn't been fixed in the latest CVS|
||0000909 is about a bug where services mode (+S?) didn't get distributed over all servers. But this is a feature request.|
And thats good so, that they are deopable !!
Normally services don´t stay at channels, except channel bots.
And ChanBots are getting +oa on join (depend on how the services are coded).
When they don´t, its a problem from the services.
It's not a good idea to forbid it for everyone!
Ah well.. each to their own.. You could make it optional?
Otherwise I'll just keep using my little hack.
||Personally (probably contrary to what you would expect) I agree with this option, there's an unkickable option too.. and a service can use every mode already (override) even if it's not +qao'd.. so it sounds logical to me to disallow -qao'ing just to look it clean. Allow it however for services and servers, and maybe for ircops too (depending on what the current behavior of +q is and what other coders think of it).|
If that will be implemented, it should allow IRCops to -qao'ing services clients. I am doing that for some reason after each services start in some channels.
And services clients are kickable, but only with Netadmin access. (Yes, thats good too)
||While it's a good idea, we are currently in a (semi-)"freeze" 'coz beta16 will get out soon... So it probably won't make it in beta16.|
It's a great idea, indeed. My reason is, if this feature is added, I won't always have to +q my service bots in channels, and even my users won't make fun of deopping them, too. In addition, Services may have the ability to operoverride, but they shouldn't do it unless they aren't channel members. Just my thoughts.
<offtopic>Rocko: a general type of Services doesn't stay in channels, that's right, but see (for instance) Quakenet for typical chanbot-style services...</offtopic>
||why shouldn't it be deopable? i think if you join a services bot you want to be able to give it every mode you want to, it can do everything it wants to - else you could make it so ircops aren't deopable because they can do everything, why should they be deopable then? just a comparision :) i think it's good how it is now.|
Why would you want servicews to stay in a channel anyhow?...
Personally, our services tell us stuff in a certain channel (new nick registrations etc...) but we don't like having all\any services in a channel as it looks messy and they really dont do anything...
But a services bot (botserv) cant be kicked, etc... so why not undeoppable as well?
;) my two cents as ever.
People like services to sit in channels to take use of easy commands.. such as
etc... as anything prefixed with a ` bypasses +d (deaf)
It also has other advantages, eg, running a 'statserv' that gives channel statistics.. and such
"People like services to sit in channels to take use of easy commands.. such as
Err... Praetorian... Our on-channel service is a botserv bot (Using Anope services. I am 99.9999999% sure that we cant deop it, cause Unreal reports user as not existing... So maybe I'm just not understanding the issue here???
edited on: 02-03-04 03:35
My previous answer was to your question "Why would you want servicews to stay in a channel anyhow?..."
Some people want them to stay in the channel to make use of 'shortened' or easier commands for their users.
If you set yourself +d (/mode nick +d), and type, you will notice you get no text unless the first character is a '`' eg '`op'
> But a services bot (botserv) cant be kicked, etc...
> so why not undeoppable as well?
Yes, i agree, that's right, good idea.
> Err... Praetorian... Our on-channel service is a botserv bot
> (Using Anope services. I am 99.9999999% sure that we cant deop
> it, cause Unreal reports user as not existing...
If it does that, then er, something is whacked at your end.
I can deop a 'Network Service' with a plain, non oper'd client :-) maybe you should try it. If it doesn't work, then either you stuffed something up, or your doing it wrong ;-)
That or anope sends out a fake numeric.. but then again, i don't use Anope :-)
> So maybe I'm just not understanding the issue here???
|Added in .2080|
|2003-04-24 23:51||shiny||New Issue|
|2003-04-24 23:54||shiny||Note Added: 0002481|
|2003-04-24 23:57||shiny||Note Added: 0002482|
|2003-04-25 10:24||mister||Note Added: 0002485|
|2003-04-25 22:59||shiny||Note Added: 0002486|
|2003-04-26 01:14||syzop||Note Added: 0002488|
|2003-04-26 16:53||Rocko||Note Added: 0002494|
|2003-04-26 21:17||shiny||Note Added: 0002498|
|2003-04-26 21:33||syzop||Note Added: 0002499|
|2003-04-27 10:08||Rocko||Note Added: 0002517|
|2003-04-27 18:09||syzop||Summary||Services? => Disallow users to deop/deown/.. services|
|2003-04-27 18:11||syzop||Note Added: 0002521|
|2003-07-08 13:11||AngryWolf||Note Added: 0003189|
|2003-07-14 23:42||_SciFi_||Note Added: 0003230|
||Status||new => assigned|
||Assigned To||=> codemastr|
|2004-02-01 22:57||w00t||Note Added: 0004850|
|2004-02-02 06:14||Praetorian_||Note Added: 0004851|
|2004-02-03 03:24||w00t||Note Added: 0004854|
|2004-02-03 03:35||w00t||Note Edited: 0004854|
|2004-02-03 04:56||Praetorian_||Note Added: 0004856|
||Status||assigned => resolved|
||Resolution||open => fixed|
||Note Added: 0004886|