Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[mmx]

I would like to point out that Services does not report to LogChan whenever a user uses either the !a/sop del or /chanserv a/sop #chan del commands.

This only seems logical to include these deletion notices because the notices are there for when a user is added, or his/her access level is changed.

Perhaps it was left out unintentionally as a "this isn't needed" feature but it only makes logical sense to me.  Perhaps you might know of a few channels that have certain 'rules' regarding the way SOPS can modify the access list.  

We currently have one main channel that is owned by a different OPER each month and at times some of their choices for SOPs decide to delete the AOP access levels of other users.

I had to add the alog() function for deletion to /src/modules/bs_fantasy_ext/xop.c and /src/core/cs_xop.c

[Edited on 26-2-2007 by mmx]

[Jan Milants]

bs_fantasy_ext implements those commands exactly as they are present in the core to keep it consistent... if it is added to the core, it will be added to the module as well.

note that by editing the source code you do lose all support in case problems arise... (both module and core)...

[katsklaw]

Services LogChan is for logging OperServ access and other global events. IRCops have never been nor should they ever be interested in knowing when a ChanOp changes channel modes, access for other users or ownership in their own channel. It's simply not the business of IRCops to know nor should they care. So what if a channel changes founders everyday? .. it's not a network issue nor does it cause harm to anything.

IRCops duties have always been network/server maintanence, not channel babysitting. It is stated in countless IRCop "howto" guides written by highly respected veteran IRCOps and in more network AUP's than I can count that IRCops do NOT interfere with channel affairs .. what happens in a channel in not the IRCops concern until a ChanOp asks for IRCop assistance. This practice has been in place for at least 12 years and frankly there is no need to change that practice now. IRCops shouldn't be interfering in the creation nor enforcement of channel rules either unless said IRCop is the owner of said channel. Th only time an oper should interfere with channel rules is when the channels rules causes the NETWORKS rules to be violated.

I'm sorry but your "logic" doesn't match the long standing practices of conventional IRC networks that have existed for 10+ years that are run by seasoned IRCops that have 15+ years of experience.

[mmx]

Services LogChan is for logging OperServ access and other global events. IRCops have never been nor should they ever be interested in knowing when a ChanOp changes channel modes, access for other users or ownership in their own channel.

Ok. I'm willing to grant you that it's technically not a concern for Admin but taken directly from a freshly unpacked, unmodified anope-1.7.18.tar.gz:

[dave@madhax core]$ grep 'access level' *
cs_access.c:                alog("%s: %s!%s@%s (level %d) set access level %d to %s (group %s) on channel %s", s_ChanServ, u->nick, u->username, u->host, ulev, access->level, na->nick, nc->display, ci->name);
cs_access.c:        alog("%s: %s!%s@%s (level %d) set access level %d to %s (group %s) on channel %s", s_ChanServ, u->nick, u->username, u->host, ulev, access->level, na->nick, nc->display, ci->name);
cs_xop.c:        alog("%s: %s!%s@%s (level %d) %s access level %d to %s (group %s) on channel %s", s_ChanServ, u->nick, u->username, u->host, ulev, change ? "changed" : "set", access->level, na->nick, nc->display, ci->name);
[dave@madhax core]$


So how come the alog() function is there to log when a user adds another to an access list if its not technically a concern?

[Dave Robson]

Just to add.... Anope's core does indeed log access level changes, anope's core does not provide fantasy commands to change levels, as such anope's core does not log when fantasy commands change access levels.  This is completely a 3rd party module issue and has nothing to do with anope's core.

[katsklaw]

mmx I apologise, I totall y mis-read your post. I stand by what I said and I dont' think that such commands should be logged but what Rob said is correct. The core can't makeup from what a 3rd party module lacks in code. You should contact the module author in regards to having it log fantasy commands to the LogChan.

[Jan Milants]

This is not completely a third party module issue though.. at least not as i read it...
The core does not report the access del command to logchan either, so i see no reason to make my module do so...

imho this isn't even an issue... as far as i m concerned it wouldn't even have to be logged at all...