feat: add self flag to message events for echo-message and znc.in/self-message#412
Open
ValwareIRC wants to merge 1 commit intokiwiirc:masterfrom
Open
feat: add self flag to message events for echo-message and znc.in/self-message#412ValwareIRC wants to merge 1 commit intokiwiirc:masterfrom
ValwareIRC wants to merge 1 commit intokiwiirc:masterfrom
Conversation
…f-message
When the echo-message cap (or the znc.in/self-message cap) is active,
the server sends back a copy of every PRIVMSG, NOTICE, ACTION, and
TAGMSG the client sends. These echoed messages arrive with the client's
own nick as the prefix and are currently indistinguishable from any
other message at the framework level, forcing each consumer to
re-implement the same nick-comparison logic.
This commit adds a boolean 'self' field to the privmsg, notice, tagmsg,
and action event payloads:
- self: true when echo-message (or znc.in/self-message) is enabled
AND the sending nick matches the connected user's nick
- self: false in all other cases
The comparison is done via client.caseCompare() so it respects the
server's CASEMAPPING setting.
Tests added in test/commands/handlers/messaging.test.js cover all four
event types, both cap variants, the cap-absent case, a mismatched nick,
and case-insensitive comparison.
Contributor
|
I'm not sure this actually solves the issue as i tried something similar with #307 but closed it due to incorrect behaviour. I think the only real solution is labeled-response, but that is going to need some major library changes to be able to track the labels after message splitting. |
Author
|
May I ask what incorrect behavior you are experiencing? This seems to work fine for me? |
Contributor
|
putting comments on why i closed a pr is something i really should learn to do, because i dont remember :( |
Author
|
Hahaha happens to everyone, give it a try, maybe it's fixed 🤪 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
When the
echo-messagecap (or theznc.in/self-messagecap) is active, the server sends back a copy of everyPRIVMSG,NOTICE,ACTION, andTAGMSGthe client sends. These echoed messages arrive with the client's own nick as the prefix and are currently indistinguishable from any other incoming message at the framework level, forcing every consumer to re-implement the same nick-comparison logic.Changes
A boolean
selffield is now included in theprivmsg,notice,tagmsg, andactionevent payloads:self: truewhenecho-messageorznc.in/self-messageis enabled AND the sending nick matches the connected user's nickself: falsein all other cases (including when no echo cap is active)The nick comparison uses
client.caseCompare()so it correctly respects the server'sCASEMAPPINGsetting.Testing
11 new tests in
test/commands/handlers/messaging.test.jscover:All 257 tests pass (246 pre-existing + 11 new).