-
Notifications
You must be signed in to change notification settings - Fork 30
Teste #6
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: master
Are you sure you want to change the base?
Teste #6
Conversation
This commit adds two new functions, offerCall and terminateCall, to the messages-recv.ts file. The offerCall function is used to initiate a call with the option to include video, while the terminateCall function is used to end an ongoing call. These functions provide additional functionality for handling calls in the application.
…ckets#956)" This reverts commit 35f6d75.
Reviewer's GuideThis PR augments the messaging layer by adding call signaling methods in the receive socket, implements support for interactive message types (buttons, template buttons, lists) across content generation and sending, extends message type definitions accordingly, and fixes the protobuf mapping for single‐select lists. Class diagram for new call signaling methods in makeMessagesRecvSocketclassDiagram
class makeMessagesRecvSocket {
+offerCall(toJid: string, isVideo: boolean)
+terminateCall(callId: string, toJid: string)
+rejectCall(callId: string, callFrom: string)
}
Class diagram for extended message content types (Buttonable, Templatable, Listable)classDiagram
class Buttonable {
+buttons: proto.Message.ButtonsMessage.IButton[]
}
class Templatable {
+templateButtons: proto.IHydratedTemplateButton[]
+footer: string
}
class Listable {
+sections: proto.Message.ListMessage.ISection[]
+title: string
+buttonText: string
}
class AnyRegularMessageContent {
}
AnyRegularMessageContent <|-- Buttonable
AnyRegularMessageContent <|-- Templatable
AnyRegularMessageContent <|-- Listable
Class diagram for message sending with interactive typesclassDiagram
class makeMessagesSocket {
+getButtonType(message: proto.IMessage)
+getButtonArgs(message: proto.IMessage): BinaryNode['attrs']
}
File-Level Changes
Tips and commandsInteracting with Sourcery
Customizing Your ExperienceAccess your dashboard to:
Getting Help
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey @cleitonme - I've reviewed your changes - here's some feedback:
- Consider extracting the buttons and list node construction logic into shared helper functions to avoid duplication between generateWAMessageContent and makeMessagesSocket.
- Extract the common call stanza creation bits into a reusable helper to reduce duplication and improve readability between offerCall and terminateCall.
- Please clarify the rationale for changing SINGLE_SELECT listType from 1 to 2 in WAProto/index.js and include compatibility tests to guard against regressions.
Prompt for AI Agents
Please address the comments from this code review:
## Overall Comments
- Consider extracting the buttons and list node construction logic into shared helper functions to avoid duplication between generateWAMessageContent and makeMessagesSocket.
- Extract the common call stanza creation bits into a reusable helper to reduce duplication and improve readability between offerCall and terminateCall.
- Please clarify the rationale for changing SINGLE_SELECT listType from 1 to 2 in WAProto/index.js and include compatibility tests to guard against regressions.
## Individual Comments
### Comment 1
<location> `src/Socket/messages-send.ts:571` </location>
<code_context>
logger.debug({ jid }, 'adding device identity')
}
+ const buttonType = getButtonType(message)
+ if(buttonType) {
+ (stanza.content as BinaryNode[]).push({
+ tag: 'biz',
+ attrs: { },
+ content: [
+ {
+ tag: buttonType,
+ attrs: getButtonArgs(message),
+ }
+ ]
+ })
+
+ logger.debug({ jid }, 'adding business node')
+ }
+
</code_context>
<issue_to_address>
Business node injection for button types may not be compatible with all message types.
Limit 'biz' node injection to supported message types or add validation to avoid malformed stanzas.
Suggested implementation:
```typescript
const buttonType = getButtonType(message)
const supportedBizTypes = ['template', 'button', 'list'] // add or adjust supported types as needed
const messageType = message.type // adjust if message type is accessed differently
if(buttonType && supportedBizTypes.includes(messageType)) {
(stanza.content as BinaryNode[]).push({
tag: 'biz',
attrs: { },
content: [
{
tag: buttonType,
attrs: getButtonArgs(message),
}
]
})
logger.debug({ jid }, 'adding business node')
}
```
- Ensure that `message.type` correctly reflects the type of the message. If the message type is determined differently in your codebase, adjust the `messageType` assignment accordingly.
- Update the `supportedBizTypes` array to include all and only the message types that should support business node injection.
</issue_to_address>
### Comment 2
<location> `src/Types/Message.ts:84` </location>
<code_context>
+ /** Title of a List Message only */
+ title?: string
+
+ /** Text of the bnutton on the list (required) */
+ buttonText?: string
+}
</code_context>
<issue_to_address>
Typo in comment: 'bnutton' should be 'button'.
Fixing the typo enhances readability and professionalism.
</issue_to_address>
<suggested_fix>
<<<<<<< SEARCH
/** Text of the bnutton on the list (required) */
buttonText?: string
=======
/** Text of the button on the list (required) */
buttonText?: string
>>>>>>> REPLACE
</suggested_fix>
Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.
const buttonType = getButtonType(message) | ||
if(buttonType) { | ||
(stanza.content as BinaryNode[]).push({ | ||
tag: 'biz', | ||
attrs: { }, | ||
content: [ | ||
{ | ||
tag: buttonType, | ||
attrs: getButtonArgs(message), | ||
} |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
suggestion (bug_risk): Business node injection for button types may not be compatible with all message types.
Limit 'biz' node injection to supported message types or add validation to avoid malformed stanzas.
Suggested implementation:
const buttonType = getButtonType(message)
const supportedBizTypes = ['template', 'button', 'list'] // add or adjust supported types as needed
const messageType = message.type // adjust if message type is accessed differently
if(buttonType && supportedBizTypes.includes(messageType)) {
(stanza.content as BinaryNode[]).push({
tag: 'biz',
attrs: { },
content: [
{
tag: buttonType,
attrs: getButtonArgs(message),
}
]
})
logger.debug({ jid }, 'adding business node')
}
- Ensure that
message.type
correctly reflects the type of the message. If the message type is determined differently in your codebase, adjust themessageType
assignment accordingly. - Update the
supportedBizTypes
array to include all and only the message types that should support business node injection.
/** Text of the bnutton on the list (required) */ | ||
buttonText?: string |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nitpick (typo): Typo in comment: 'bnutton' should be 'button'.
Fixing the typo enhances readability and professionalism.
/** Text of the bnutton on the list (required) */ | |
buttonText?: string | |
/** Text of the button on the list (required) */ | |
buttonText?: string |
Summary by Sourcery
Enable voice/video call initiation and termination via the socket API, and add full support for interactive message formats (buttons, templates, and lists) across content generation, sending logic, and type definitions, with a related Proto enum mapping correction.
New Features:
Bug Fixes:
Enhancements: