View Issue Details

IDProjectCategoryView StatusLast Update
0002682unrealircdpublic2015-08-08 17:58
Reporterw00t Assigned Tosyzop  
PrioritynormalSeverityminorReproducibilityalways
Status resolvedResolutionduplicate 
OSn/a 
Product Version3.2.3 
Summary0002682: HOOKTYPE_LOCAL_NICKCHANGE (etc) and HOOK_DENY
DescriptionThey 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 ;).
TagsNo tags attached.
3rd party modules

Relationships

duplicate of 0002337 closedsyzop Add HOOKTYPE_PRE_NICK 

Activities

syzop

2005-11-10 10:44

administrator   ~0010684

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.

w00t

2005-11-10 22:13

reporter   ~0010690

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.

Issue History

Date Modified Username Field Change
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
2007-04-27 04:40 stskeeps 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