[IRCServices Coding] 5.0.36 and Unreal

[Aragon Gouveia]

| 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