View Issue Details

IDProjectCategoryView StatusLast Update
0000917unrealircdpublic2004-02-05 22:58
Reportershiny Assigned Tocodemastr 
PrioritynormalSeverityfeatureReproducibilityalways
Status resolvedResolutionfixed 
Platform*nixOSLinux 2.4.18-14 
Product Version3.2-beta15 
Summary0000917: Disallow users to deop/deown/.. services
DescriptionOn-channel services are allowed to be deopped. Can you fix this in the next beta pls?
Steps To Reproduce/mode #chan -o SomeService
Additional InformationI'm using this as a bit of a hack in the mean time:
in channel.c:

                                if (IsServices(who) && (!IsServer(sptr)))
                                {
                                        if (!IsNetAdmin(sptr))
                                        {
                                                sendto_one(sptr,
                                                    ":%s %s %s :*** Cannot kick %s from channel %s, it is a network service",
                                                    me.name, IsWebTV(sptr) ? "PRIVMSG" : "NOTICE", sptr->name,
                                                    who->name, chptr->chname);
                                                goto deny;
                                        }
                                }





Wow, C code looks ugly in these text boxes :D
TagsNo tags attached.
3rd party modules

Activities

shiny

2003-04-24 23:54

reporter   ~0002481

errrr... did i paste the wrong bit of code :/

shiny

2003-04-24 23:57

reporter   ~0002482

I did ... sorry


                  if (IsServices(member->cptr)
                        && (!IsServer(cptr))
                        && (what == MODE_DEL))
                  {
                          if (MyClient(cptr))
                          {
                                  sendto_one(cptr,
                                      ":%s %s %s :*** You cannot %s %s in %s, it is a network service.",
                                      me.name, IsWebTV(cptr) ? "PRIVMSG" : "NOTICE", cptr->name, xxx,
                                      member->cptr->name, chptr->chname);
                          }
                          break;
                  }
                  breaktherules:
                  ... as before

mister

2003-04-25 10:24

reporter   ~0002485

look 0000909
and get the CVS version

shiny

2003-04-25 22:59

reporter   ~0002486

maybe i'm blind, but huh? my query had nothing to do with /whois... and it hasn't been fixed in the latest CVS

syzop

2003-04-26 01:14

administrator   ~0002488

0000909 is about a bug where services mode (+S?) didn't get distributed over all servers. But this is a feature request.

Rocko

2003-04-26 16:53

reporter   ~0002494

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!

shiny

2003-04-26 21:17

reporter   ~0002498

Ah well.. each to their own.. You could make it optional?

Otherwise I'll just keep using my little hack.

syzop

2003-04-26 21:33

administrator   ~0002499

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).

Rocko

2003-04-27 10:08

reporter   ~0002517

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)

syzop

2003-04-27 18:11

administrator   ~0002521

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.

AngryWolf

2003-07-08 13:11

reporter   ~0003189

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>

_SciFi_

2003-07-14 23:42

reporter   ~0003230

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.

w00t

2004-02-01 22:57

reporter   ~0004850

Err...

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.

Praetorian_

2004-02-02 06:14

reporter   ~0004851

People like services to sit in channels to take use of easy commands.. such as

`op
`kick

etc... as anything prefixed with a ` bypasses +d (deaf)

It also has other advantages, eg, running a 'statserv' that gives channel statistics.. and such

w00t

2004-02-03 03:24

reporter   ~0004854

Last edited: 2004-02-03 03:35

"People like services to sit in channels to take use of easy commands.. such as
`op
`kick"

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

Praetorian_

2004-02-03 04:56

reporter   ~0004856

w00t:
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.

--Post 2--
> 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???

Agreed.

codemastr

2004-02-05 22:58

reporter   ~0004886

Added in .2080

Issue History

Date Modified Username Field Change
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
2004-02-01 05:42 codemastr Status new => assigned
2004-02-01 05:42 codemastr 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
2004-02-05 22:58 codemastr Status assigned => resolved
2004-02-05 22:58 codemastr Resolution open => fixed
2004-02-05 22:58 codemastr Note Added: 0004886