[IRCServices Coding] 5.0.36 and Unreal

[Martin Pels]

> I suspect I'm the only one with this opinion.

Nope, I completely agree :-)

The mode +q is given to channel owners only, and because of this it
should not be possible for users with accesslevel 100 (channel admin) to
remove this mode (if they can this makes +q useless, because after
removing +q through Services a channel admin will be able to kick the
owner). So PROTECT/DEPROTECT should only add or remove +a.

On Mon, 2004-07-26 at 16:23, Aragon Gouveia wrote:
> | By Andrew Church <achurch at achurch.org>
> |                                          [ 2004-07-26 15:31 +0200 ]
> >      Actually, what would be best from my perspective is if someone--or
> > even better, several someones--made their own hacks to Services on their
> > own network to do what they thought was the "right thing", and some sort of
> > consensus arose from there.  (I often look to Services derivatives for
> > ideas as well; is anyone aware of a Services-like program that does use the
> > channel owner mode, and if so, how does it use the mode?)
> 
> I don't know of anything apart from the IRCd itself.
> 
> 
> >      I think a lot of the problem is that chanowner and protected (+a)
> > overlap too much--there isn't anything a chanowner can _do_ other than not
> > get de-ownered(?) by +a users, and maybe set a couple of modes that could
> > be just as easily handled by SET MLOCK.  At the moment it's just an
> > extraneous, unnecessary privilege level, and I think that's what's causing
> > a lot of the confusion.
> 
> Yea, that's right.
> 
> Current Unreal protocol dictates that
>    channel owners (+q) can:
>         Set the channel +u
>         Set the channel +L
>         Set a channel user +a
>         Set a channel user +q
>         Set all other channel modes normal chanops can set
>         Kick anyone in the channel
>         NOT be kicked by anyone but another owner
>         NOT be deopped by anyone but another owner
>         NOT be de-q'd by anyone but another owner
>         NOT be de-a'd by anyone but another owner
> 
>    channel admins (+a) can:
>         Set the same channel modes normal chanops can set
>         NOT be kicked by anyone but an owner 
>         NOT be deopped by anyone but an owner
>         NOT be de-a'd by anyone but an owner
> 	NOT kick other channel admins
> 	NOT deop other channel admins
>         NOT de-a other channel admins
> 
> 
> The confusion for me is this:
> 
> -ChanServ-     PROTECT    Give a user protected status (+a)
> -ChanServ-     DEPROTECT  Remove protected status (+a)
> 
> The (DE)PROTECT commands are labelled as being capable of adding/removing
> +a status.  However, the DEPROTECT command will remove +a and +q. 
> Additionally, channel admin status is essentially just a chanop status
> providing kick/deop protection.  Channel ownership is more than that, which
> is why I think DEPROTECT should not have the ability of removing that
> status.  IMHO that control should be reserved for the ChanServ
> FOUNDER, SUCCESSOR, and holder(s) of the founder password.
> 
> I suspect I'm the only one with this opinion.  In which case, no worries..
> will mod the source.  I originally posted thinking it'd be a simple bug
> report. :)
> 
> 
> Regards,
> Aragon
> 
> ------------------------------------------------------------------
> To unsubscribe or change your subscription options, visit:
> http://www.ircservices.za.net/mailman/listinfo/ircservices-coding