tracker: findUser is sensitive to nick prefixes
Closed this issue · 3 comments
If a user is voiced, hop, op, superop, etc., findUser() fails for that nick because the tracker tracks it as e.g. "~nick" instead of "nick".
This is especially crippling when Diggler is looking for admins and the admin user currently has a mode set like voice in the channel he is in.
Possible solution: Parse servers options when connecting and strip the characters in PREFIX, i.e. PREFIX=(qaohv)~&@%+ would mean ~, &, @, % and + are nick prefixes for owner, admin, op, hop and voice.
If a user is voiced, hop, op, superop, etc., findUser() fails for that nick because the tracker tracks it as e.g. "~nick" instead of "nick".
Yeah, Dirk has no consistent handling of nick prefixes or user modes yet. I'm unsure of how to best present that information in the interface; onNameList currently strips the two standard nick prefixes (@ and +), with no handling of non-standard ones, and there is no handling of user prefixes anywhere else in the code (as far as I can remember). Sticking some flags on IrcUser to track user modes might be a good solution, but I don't know...
This is especially crippling when Diggler is looking for admins and the admin user currently has a mode set like voice in the channel he is in.
Until the user mode thing is properly part of Dirk, we should probably just strip the prefix in the tracker.
Possible solution: Parse servers options when connecting and strip the characters in PREFIX, i.e. PREFIX=(qaohv)~&@%+ would mean ~, &, @, % and + are nick prefixes for owner, admin, op, hop and voice.
Yeah, there's a LOT of information in 005 that Dirk can take advantage of, and PREFIX should definitely be leveraged here. It's not part of the RFC specification, though it is documented semi-officially in this document, and I'm guessing most networks use 005 in this sense. Maybe some well-defined fallback behaviour is still in order, though...
Handler code for both 353 and 319 now take care of channel mode prefixes, and according to the ISUPPORT documentation, these replies should be the only ones using these prefixes, so this is fixed for now.
Modes still need to be presented to the user in some way.
Nice, thanks