View Issue Details
|ID||Project||Category||View Status||Date Submitted||Last Update|
|0002682||unreal||ircd||public||2005-11-09 23:50||2015-08-08 17:58|
|Summary||0002682: HOOKTYPE_LOCAL_NICKCHANGE (etc) and HOOK_DENY|
|Description||They don't respect HOOK_DENY, so I can't do what I was trying to do as a proof-of-concept today, a modular +N chmode.|
I'll have a patch up in a day or so, due to family concerns I'm not able to get on the internet at home- which is why it's taking me so long to get anything done.. I'll spare you the convoluted details ;).
|Tags||No tags attached.|
|3rd party modules|
The idea is btw to have any "is <X> allowed?" hooks that can return HOOK_DENY to be moved to "PRE hooks". So that should probably be a HOOKTYPE_PRE_LOCAL_NICKCHANGE then.
That way, any module catching HOOKTYPE_LOCAL_NICKCHANGE can be sure the nickchange actually succeeded. Otherwise, module 1 (eg: a nickchange logging module) might think the nick got changed, while module 2 (next in list) aborts the nickchange.
Some early-implemented hooks (eg HOOKTYPE_USERMSG and HOOKTYPE_CHANMSG) are therefore not "100% correctly" implemented. Though, changing that will break modules, so we'll keep it like that for now for the 3.2* stable series.
Yeah, I was thinking about that after.
Another point (dunno whether I need to make a tracker item on this) is we really need to wrap this 'check-for-deny-from-a-callback' crap in a function so we don't need to continually duplicate it.
|2005-11-09 23:50||w00t||New Issue|
|2005-11-10 10:44||syzop||Note Added: 0010684|
|2005-11-10 22:13||w00t||Note Added: 0010690|
||Status||new => acknowledged|
|2015-08-08 17:58||syzop||Relationship added||duplicate of 0002337|
|2015-08-08 17:58||syzop||Status||acknowledged => resolved|
|2015-08-08 17:58||syzop||Resolution||open => duplicate|
|2015-08-08 17:58||syzop||Assigned To||=> syzop|