Closed kaniini closed 4 years ago
@aaronmdjones what is the current blockers on this? i have validated that the module works fine in a complex network topology.
@kaniini I have not yet had the time to testnet it. Should be done by tomorrow evening.
@kaniini This appears to break the behaviour of automatically adding PRIVMSG
targets to your /ACCEPT
list.
17:42 <Aaron1> Hi
17:42 <Aaron3> Hi
17:42 -!- [chary1.testnet] Aaron1 is in +g mode (server-side ignore.)
17:42 -!- [chary1.testnet] Aaron1 has been informed that you messaged them.
This was resolved by changing the scope of the privmsg_user
hook. I verified that all hook subscribers are safe with this change.
Okay, it does indeed all work now.
My only remaining concerns are:
1) This user mode +G
behaves differently from the user mode +G
in hybrid, which this idea comes from. In hybrid, it's a self-contained mode, and can be set and unset independently of +g
, rather than modifying its behaviour. Making this behave like that would be a relatively minor adjustment to your if statements, and I believe is a worthwhile change.
Something to bear in mind though is that the source will need to receive a different error text (mentioning user mode `+G` instead of `+g`) if the message is not allowed, and the umode help file will need to be updated again.
EDIT: Also, it should check for `+g` first.
2) The change to the privmsg_user
hook is indeed safe, but now extensions/umode_noctcp.c
needs this in umode_noctcp_process
, or it will be pointlessly checking for the user mode +C
twice:
if (! MyClient(data->target_p))
return;
This MR is the second part of refactoring the message forwarding path in the IRCd. We also add a relaxed caller id mode which works similarly to Hybrid's soft callerid as usermode +G.