format whatsapp number for brazilian rules #201
Conversation
WalkthroughThe changes in this pull request introduce several enhancements across multiple files. Notably, new global variables and functions are added to manage configuration settings related to media synchronization and number formatting. The Changes
Possibly related PRs
Thank you for using CodeRabbit. We offer it for free to the OSS community and would appreciate your support in helping us grow. If you find it useful, would you consider giving us a shout-out on your favorite social media? 🪧 TipsChatThere are 3 ways to chat with CodeRabbit:
Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments. CodeRabbit Commands (Invoked using PR comments)
Other keywords and placeholders
CodeRabbit Configuration File (
|
![coderabbitai[bot]](https://avatars.githubusercontent.com/in/347564?s=60&v=4){kind=small}
There was a problem hiding this comment.
Actionable comments posted: 7
🧹 Outside diff range and nitpick comments (19)
src/views/components/MessageRevoke.js (1)
15-15: LGTM: phone_id computed property updated correctly.The
phone_idcomputed property has been successfully updated to use theNumberFormatLocalefunction, which aligns with the PR objectives to enhance handling of WhatsApp numbers for specific formatting rules.Consider improving readability by breaking the long line into multiple lines:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }src/views/components/AccountUserInfo.js (1)
20-20: Approve change with suggestion for error handlingThe modification to the
phone_idcomputed property correctly implements theNumberFormatLocalefunction, aligning with the PR objectives. The existing logic for differentiating between user and group types is preserved.However, consider adding error handling for potential exceptions that
NumberFormatLocalemight throw:Consider wrapping the
NumberFormatLocalecall in a try-catch block to handle potential formatting errors gracefully. Here's a suggested implementation:phone_id() { try { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; } catch (error) { console.error('Error formatting phone number:', error); return this.type === 'user' ? `${this.phone}@${window.TYPEUSER}` : `${this.phone}@${window.TYPEGROUP}`; } }This approach ensures that even if
NumberFormatLocalefails, the component will still function using the unformatted phone number.src/views/components/SendAudio.js (1)
14-14: LGTM with a minor suggestion: phone_id computed propertyThe modification correctly applies the
NumberFormatLocalefunction tothis.phone, which aligns with the PR objectives. The conditional logic for user vs. group type is preserved.For improved readability, consider splitting the line:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }This change is optional and doesn't affect functionality.
src/views/components/MessageReact.js (1)
16-16: LGTM with suggestion: phone_id computed property updateThe use of
NumberFormatLocaleto format the phone number in thephone_idcomputed property is correct and aligns with the PR objectives. However, consider adding a conditional check to apply this formatting only when theNumberFormatLocaleis set to "Brazil" in the configuration. This would ensure that the formatting is applied selectively based on the locale settings.Example:
phone_id() { const formattedPhone = window.NumberFormatLocale === 'Brazil' ? NumberFormatLocale(this.phone) : this.phone; return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }src/views/components/AccountAvatar.js (1)
17-17: Approve with suggestion: Ensure robust string concatenation in phone_id computed propertyThe modification correctly applies the
NumberFormatLocalefunction to format the phone number before constructing thephone_id. This aligns with the PR objectives of enhancing WhatsApp number handling for Brazilian formatting rules.However, to improve robustness, consider ensuring that the result of
NumberFormatLocaleis always a string before concatenation.Consider modifying the line as follows:
return this.type === 'user' ? `${String(NumberFormatLocale(this.phone))}@${window.TYPEUSER}` : `${String(NumberFormatLocale(this.phone))}@${window.TYPEGROUP}`This change ensures that even if
NumberFormatLocalereturns a non-string value (e.g.,undefinedornull), it will be converted to a string before concatenation, preventing potential runtime errors.src/views/components/SendContact.js (1)
16-16: LGTM: phone_id computed property updated with NumberFormatLocaleThe
phone_idcomputed property has been correctly updated to use theNumberFormatLocalefunction for formatting phone numbers. This change aligns with the PR objectives and should enhance WhatsApp number handling for Brazilian formatting rules.For improved readability, consider extracting the formatted phone number to a separate variable:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }This change would make the code more readable and reduce repetition.
src/views/components/SendMessage.js (1)
16-16: LGTM: phone_id computed property updated with NumberFormatLocaleThe
phone_idcomputed property has been correctly updated to use theNumberFormatLocalefunction, which aligns with the PR objectives of formatting WhatsApp numbers according to specific rules (e.g., Brazilian format).For improved readability, consider extracting the formatted phone number to a separate variable:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }This change would make the code more readable and reduce repetition.
src/views/components/SendFile.js (1)
Line range hint
1-21: Summary: Changes align with PR objectives, consider additional locale-specific enhancementsThe changes in this file successfully implement the use of
NumberFormatLocalefor formatting WhatsApp numbers, which aligns with the PR objectives. The implementation is correct and enhances the handling of both user and group phone numbers.To further improve the implementation:
- Consider adding a check for the 'Brazil' locale in the
phone_idcomputed property to ensure the formatting is only applied when necessary.- It might be beneficial to add unit tests for the
phone_idcomputed property to verify its behavior with different locales and phone number formats.These enhancements would ensure that the implementation fully meets the PR objectives and maintains flexibility for future locale-specific requirements.
src/views/components/SendPoll.js (1)
18-18: LGTM: phone_id computed property updated with NumberFormatLocaleThe modification to apply
NumberFormatLocaletothis.phonein thephone_idcomputed property is correct and aligns with the PR objectives. This change ensures that phone numbers are formatted according to the specified locale rules before being used.For improved readability, consider extracting the formatted phone number to a separate variable:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }This suggestion is optional and aims to enhance code clarity.
src/views/components/SendImage.js (1)
18-18: LGTM: Phone number formatting is correctly implemented.The use of
NumberFormatLocalefunction to format the phone number aligns with the PR objectives and should improve number handling for Brazilian users without affecting other locales.Consider improving readability by breaking the line into multiple lines:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); const suffix = this.type === 'user' ? window.TYPEUSER : window.TYPEGROUP; return `${formattedPhone}@${suffix}`; }This change would make the code easier to read and maintain.
src/views/components/SendVideo.js (1)
24-24: LGTM: phone_id computed property updated with NumberFormatLocaleThe
phone_idcomputed property has been correctly updated to use theNumberFormatLocalefunction for formatting the phone number. This change aligns with the PR objectives to implement number formatting based on locale settings.For improved readability, consider extracting the formatted phone number to a separate variable:
phone_id() { const formattedPhone = NumberFormatLocale(this.phone); return this.type === 'user' ? `${formattedPhone}@${window.TYPEUSER}` : `${formattedPhone}@${window.TYPEGROUP}`; }This minor refactoring would make the code slightly more readable and easier to maintain.
src/internal/rest/send.go (2)
33-34: LGTM! Consider adding error handling forNumberFormatLocale.The addition of
utils.NumberFormatLocalealigns with the PR objectives for formatting WhatsApp numbers. The order of operations (format then sanitize) is logical.Consider adding error handling for
NumberFormatLocaleif it can return an error:formattedPhone, err := utils.NumberFormatLocale(request.Phone) if err != nil { return c.Status(fiber.StatusBadRequest).JSON(utils.ResponseData{ Status: 400, Code: "BAD_REQUEST", Message: "Invalid phone number format", }) } request.Phone = formattedPhone
Line range hint
1-215: Consider refactoring to reduce code duplication.The phone number formatting and sanitization logic is repeated across all methods. Consider extracting this logic into a separate function to reduce code duplication and improve maintainability.
Here's a suggested refactoring:
- Create a new function in the
Sendstruct:func (controller *Send) formatAndSanitizePhone(phone string) (string, error) { formattedPhone, err := utils.NumberFormatLocale(phone) if err != nil { return "", err } whatsapp.SanitizePhone(&formattedPhone) return formattedPhone, nil }
- Replace the repeated logic in each method with a call to this new function:
formattedPhone, err := controller.formatAndSanitizePhone(request.Phone) if err != nil { return c.Status(fiber.StatusBadRequest).JSON(utils.ResponseData{ Status: 400, Code: "BAD_REQUEST", Message: "Invalid phone number format", }) } request.Phone = formattedPhoneThis refactoring will centralize the phone number processing logic, making it easier to maintain and update in the future.
src/pkg/whatsapp/whatsapp.go (3)
285-301: LGTM with a minor style suggestion.The addition of the
IgnoreExtractHistoryflag is a good improvement, allowing more control over the history sync process. This aligns well with the PR objectives.Consider adjusting the brace placement for consistency with Go style guidelines:
-if !config.IgnoreExtractHistory{ +if !config.IgnoreExtractHistory {
459-498: LGTM with a minor indentation suggestion.The addition of the
IgnoreExtractMediaflag is a valuable improvement, providing more control over the media extraction process. This aligns well with the PR objectives.Consider adjusting the indentation of the entire block inside the new condition for better readability:
if !config.IgnoreExtractMedia { - if mediaFile == nil { - logrus.Info("Skip download because data is nil") - return extractedMedia, nil - } + if mediaFile == nil { + logrus.Info("Skip download because data is nil") + return extractedMedia, nil + } - data, err := cli.Download(mediaFile) - if err != nil { - return extractedMedia, err - } + data, err := cli.Download(mediaFile) + if err != nil { + return extractedMedia, err + } - switch media := mediaFile.(type) { - case *waE2E.ImageMessage: - extractedMedia.MimeType = media.GetMimetype() - extractedMedia.Caption = media.GetCaption() - case *waE2E.AudioMessage: - extractedMedia.MimeType = media.GetMimetype() - case *waE2E.VideoMessage: - extractedMedia.MimeType = media.GetMimetype() - extractedMedia.Caption = media.GetCaption() - case *waE2E.StickerMessage: - extractedMedia.MimeType = media.GetMimetype() - case *waE2E.DocumentMessage: - extractedMedia.MimeType = media.GetMimetype() - extractedMedia.Caption = media.GetCaption() - } + switch media := mediaFile.(type) { + case *waE2E.ImageMessage: + extractedMedia.MimeType = media.GetMimetype() + extractedMedia.Caption = media.GetCaption() + case *waE2E.AudioMessage: + extractedMedia.MimeType = media.GetMimetype() + case *waE2E.VideoMessage: + extractedMedia.MimeType = media.GetMimetype() + extractedMedia.Caption = media.GetCaption() + case *waE2E.StickerMessage: + extractedMedia.MimeType = media.GetMimetype() + case *waE2E.DocumentMessage: + extractedMedia.MimeType = media.GetMimetype() + extractedMedia.Caption = media.GetCaption() + } - var extension string - if ext, err := mime.ExtensionsByType(extractedMedia.MimeType); err != nil && len(ext) > 0 { - extension = ext[0] - } else if parts := strings.Split(extractedMedia.MimeType, "/"); len(parts) > 1 { - extension = "." + parts[len(parts)-1] - } + var extension string + if ext, err := mime.ExtensionsByType(extractedMedia.MimeType); err != nil && len(ext) > 0 { + extension = ext[0] + } else if parts := strings.Split(extractedMedia.MimeType, "/"); len(parts) > 1 { + extension = "." + parts[len(parts)-1] + } - extractedMedia.MediaPath = fmt.Sprintf("%s/%d-%s%s", storageLocation, time.Now().Unix(), uuid.NewString(), extension) - err = os.WriteFile(extractedMedia.MediaPath, data, 0600) - if err != nil { - return extractedMedia, err - } - } + extractedMedia.MediaPath = fmt.Sprintf("%s/%d-%s%s", storageLocation, time.Now().Unix(), uuid.NewString(), extension) + err = os.WriteFile(extractedMedia.MediaPath, data, 0600) + if err != nil { + return extractedMedia, err + } + }
Line range hint
1-498: Overall, the changes look good and align well with the PR objectives.The implementation of
IgnoreExtractHistoryandIgnoreExtractMediaflags provides the desired control over media and history synchronization. These additions allow the tool to function solely for sending messages when media extraction from the phone is not desired, as mentioned in the PR objectives.The changes are implemented correctly and don't introduce any logical errors. Only minor style and indentation issues were noted in the previous comments.
Consider adding logging statements when media or history extraction is skipped due to the new configuration flags. This would improve debugging and provide better visibility into the application's behavior based on these settings.
src/views/components/funcoes.js (1)
6-6: Remove unnecessary console logThe
console.log(config.NumberFormatLocale);statement is primarily for debugging purposes. It may not be necessary in production code.Consider removing or commenting out the console log:
- console.log(config.NumberFormatLocale);src/config/settings.go (2)
33-35: Enhance clarity of comments for configuration variablesThe comments for
IgnoreExtractMedia,IgnoreExtractHistory, andNumberFormatLocalecan be improved for better readability and understanding.Apply this diff to improve the comments:
-IgnoreExtractMedia = false // Skip sync media to storages folder (jpg ...) -IgnoreExtractHistory = false // Skip sync history to storages folder -NumberFormatLocale = "" // Empty to maintain the current process or "Brazil" to use the WhatsApp number pattern for the country +IgnoreExtractMedia = false // Set to true to skip syncing media files (e.g., JPG) to the storages folder +IgnoreExtractHistory = false // Set to true to skip syncing chat history to the storages folder +NumberFormatLocale = "" // Leave empty to maintain current behavior or set to "Brazil" to apply Brazilian WhatsApp number formatting rules
38-38: Correct the typo in the commentThe comment refers to
NumberFormatLocal, but the variable isNumberFormatLocale.Apply this diff to fix the typo:
-func envHandler(w http.ResponseWriter, r *http.Request) { // exposes the NumberFormatLocal variable for use in JS functions +func envHandler(w http.ResponseWriter, r *http.Request) { // exposes the NumberFormatLocale variable for use in JS functions
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
📒 Files selected for processing (19)
- src/config/settings.go (2 hunks)
- src/internal/rest/send.go (9 hunks)
- src/pkg/utils/general.go (2 hunks)
- src/pkg/whatsapp/whatsapp.go (2 hunks)
- src/views/components/AccountAvatar.js (2 hunks)
- src/views/components/AccountUserInfo.js (2 hunks)
- src/views/components/MessageDelete.js (2 hunks)
- src/views/components/MessageReact.js (2 hunks)
- src/views/components/MessageRevoke.js (2 hunks)
- src/views/components/MessageUpdate.js (2 hunks)
- src/views/components/SendAudio.js (2 hunks)
- src/views/components/SendContact.js (2 hunks)
- src/views/components/SendFile.js (2 hunks)
- src/views/components/SendImage.js (2 hunks)
- src/views/components/SendLocation.js (2 hunks)
- src/views/components/SendMessage.js (2 hunks)
- src/views/components/SendPoll.js (2 hunks)
- src/views/components/SendVideo.js (2 hunks)
- src/views/components/funcoes.js (1 hunks)
🧰 Additional context used
🔇 Additional comments (38)
src/pkg/utils/general.go (1)
5-5: LGTM: New import added correctly.The import for the
configpackage is correctly added and is necessary for accessing theNumberFormatLocalevariable used in the new function.src/views/components/MessageRevoke.js (2)
1-1: LGTM: Import statement for NumberFormatLocale is correct.The import statement for
NumberFormatLocalefrom './funcoes.js' is correctly placed and aligns with the PR objectives to introduce number formatting for different locales.
Line range hint
1-15: Verify the impact of NumberFormatLocale on application behavior.The introduction of
NumberFormatLocalein this component is a good step towards consistent phone number formatting. However, it's important to ensure that this change doesn't negatively impact the existing functionality of the application.Please run the following script to check for any inconsistencies in phone number formatting across the application:
This script will help identify any areas where the new
NumberFormatLocalefunction should be used but might have been overlooked, ensuring consistency across the application.src/views/components/AccountUserInfo.js (1)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom './funcoes.js' is correctly implemented and aligns with the PR objectives of introducing number formatting functionality.src/views/components/MessageDelete.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement correctly introduces the
NumberFormatLocalefunction from the local 'funcoes.js' file. This aligns with the PR objectives and is necessary for the subsequent use in the component.
15-15: LGTM: Phone number formatting appliedThe modification correctly applies the
NumberFormatLocalefunction to format the phone number before constructing thephone_id. This change aligns with the PR objectives for handling Brazilian number formats.Please ensure that the
NumberFormatLocalefunction infuncoes.jshandles non-Brazilian numbers appropriately, maintaining the existing behavior for other locales whenNumberFormatLocalein the configuration is not set to "Brazil".To verify this, you can run the following script:
This script will help ensure that the
NumberFormatLocalefunction is implemented correctly and handles non-Brazilian numbers appropriately.✅ Verification successful
<!-- [monologue] [task verification/1] Review the output of the shell scripts regarding the NumberFormatLocale function. [observations] - The `NumberFormatLocale` function is defined in `src/views/components/funcoes.js` starting at line 12. - The function checks if the locale is "Brazil" and applies specific formatting; otherwise, it returns the number unchanged. - The shell script confirmed that there is a condition handling the "Brazil" locale and an else case that returns the number as is. [analysis] - The modification introduced the `NumberFormatLocale` function to format phone numbers for Brazilian locale. - For non-Brazilian locales, the function maintains the original behavior by returning the number without formatting. - This ensures that existing functionality is preserved for all other locales, addressing the reviewer's concern. [actions] - Since the `NumberFormatLocale` function correctly handles both Brazilian and non-Brazilian numbers, the verification is successful. - No further scripts are necessary. -->Verified: NumberFormatLocale handles non-Brazilian numbers correctly
The
NumberFormatLocalefunction effectively formats Brazilian phone numbers while maintaining the original behavior for non-Brazilian numbers. This ensures consistency across different locales as intended.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of NumberFormatLocale function # Test: Check the implementation of NumberFormatLocale in funcoes.js echo "Checking NumberFormatLocale implementation in funcoes.js:" ast-grep --lang javascript --pattern 'function NumberFormatLocale($_) { $$$ }' # Test: Check if there's a condition for handling non-Brazilian numbers echo "Checking for non-Brazilian number handling:" rg --type js 'NumberFormatLocale.*Brazil' src/views/components/funcoes.jsLength of output: 1237
src/views/components/SendAudio.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom './funcoes.js' is correctly placed and aligns with the PR objectives of introducing number formatting functionality.
Line range hint
1-14: Verify NumberFormatLocale implementationThe changes introduce number formatting for WhatsApp numbers, which aligns with the PR objectives. However, to ensure full compliance with the stated goals:
- Verify that the
NumberFormatLocalefunction in './funcoes.js' correctly implements the Brazilian formatting rules.- Confirm that it handles both formats with and without the digit '9' for Brazilian numbers.
- Ensure that it doesn't affect number formatting for other regions when not set to "Brazil".
To assist with this verification, you can run the following script:
This script will help verify the implementation details of
NumberFormatLocaleand ensure it meets the requirements specified in the PR objectives.✅ Verification successful
NumberFormatLocale Implementation Verified
The
NumberFormatLocalefunction in./funcoes.jscorrectly implements the Brazilian formatting rules as intended:
- Brazil-Specific Logic: The function checks for the "Brazil" locale and prefixes numbers with '55' if necessary.
- Handling Digit '9': It properly handles cases where the fifth digit is '9' for numbers with a length of 13, ensuring accurate formatting.
- Non-Impact on Other Regions: The implementation ensures that number formatting for other regions remains unaffected when the locale is not set to "Brazil".
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of NumberFormatLocale # Test: Check the implementation of NumberFormatLocale in funcoes.js echo "Checking NumberFormatLocale implementation:" ast-grep --lang javascript --pattern $'export function NumberFormatLocale($_) { $$$ }' # Test: Check for Brazil-specific logic echo "Checking for Brazil-specific logic:" rg --type js "Brazil" ./src/views/components/funcoes.js # Test: Check for handling of digit '9' echo "Checking for handling of digit '9':" rg --type js "9" ./src/views/components/funcoes.jsLength of output: 1377
src/views/components/MessageReact.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import of
NumberFormatLocalefrom './funcoes.js' is correctly placed and aligns with the PR objectives to enhance WhatsApp number formatting.
Line range hint
1-138: Overall impact assessment and suggestion for additional featuresThe changes to this component effectively implement the number formatting feature for WhatsApp numbers, aligning with the PR objectives. The modifications are minimal and focused, which is good for maintainability and reduces the risk of unintended side effects.
However, I noticed that the new configuration variables mentioned in the PR objectives (
IgnoreExtractMediaandIgnoreExtractHistory) are not utilized in this component. Consider if these variables should be incorporated into this component's logic, especially if they affect message reactions or the display of messages.To ensure that these configuration variables are properly implemented elsewhere in the codebase, you may want to run the following verification script:
This will help confirm that these new configuration variables are being used appropriately in the codebase.
src/views/components/AccountAvatar.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom./funcoes.jsis correctly added. This aligns with the PR objectives of introducing number formatting based on locale.
Line range hint
1-17: Overall impact: Consider updating related testsThe changes to import
NumberFormatLocaleand use it in thephone_idcomputed property align well with the PR objectives. They enhance the handling of WhatsApp numbers for Brazilian formatting rules without significantly altering the component's structure or behavior.However, these changes may impact how phone numbers are displayed and used in API calls.
To ensure the changes don't introduce any regressions:
- Please verify that any existing unit tests for this component are updated to reflect the new number formatting behavior.
- Consider adding new test cases that specifically check the formatting for Brazilian phone numbers.
Run the following script to check for existing tests related to this component:
If test files are found, please review and update them accordingly.
src/views/components/SendLocation.js (3)
1-1: LGTM: Import statement is correct and necessary.The import of
NumberFormatLocalefrom './funcoes.js' is correctly formatted and is required for the changes in thephone_idcomputed property.
Line range hint
1-16: Overall impact: Enhanced locale-specific phone number handling.The changes to this component improve its ability to handle phone number formatting based on locale settings, specifically addressing the PR objective for Brazilian number formatting. The modifications are well-contained and don't affect other parts of the component.
To ensure the changes don't negatively impact existing functionality:
- Test the component with Brazilian phone numbers to confirm correct formatting.
- Verify that the component still works correctly for non-Brazilian locales.
- Check that the
NumberFormatLocalefunction infuncoes.jsgracefully handles undefined or empty locale settings.Consider adding unit tests for the
phone_idcomputed property to cover various locale scenarios.
16-16: LGTM: Phone number formatting enhanced, but verify non-Brazilian locales.The modification to apply
NumberFormatLocaletothis.phonealigns with the PR objective of enhancing WhatsApp number handling for Brazilian formatting rules. This change improves the flexibility of phone number formatting based on locale settings.Please ensure that the
NumberFormatLocalefunction infuncoes.jshandles non-Brazilian locales correctly, maintaining existing functionality for other regions. Run the following script to verify the implementation:src/views/components/MessageUpdate.js (2)
1-1: LGTM: Import statement correctly added.The import of
NumberFormatLocalefrom./funcoes.jsis correctly placed and will be used in thephone_idcomputed property.
16-16: Approve change with a suggestion for verification.The modification to use
NumberFormatLocalefor formatting phone numbers aligns with the PR objectives. However, it's important to ensure that this change doesn't negatively impact non-Brazilian locales.Please verify that the
NumberFormatLocalefunction infuncoes.jshandles non-Brazilian locales appropriately, possibly by returning the original number format when the locale is not set to Brazil.✅ Verification successful
Approve change.
The
NumberFormatLocalefunction correctly returns the original number format for non-Brazilian locales, ensuring consistency across different regions.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation of NumberFormatLocale function # Test: Check the implementation of NumberFormatLocale ast-grep --lang javascript --pattern $'export function NumberFormatLocale($_) { $$$ }'Length of output: 901
src/views/components/SendContact.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocaleis correctly placed and aligns with the PR objectives of introducing number formatting for Brazilian rules.
Line range hint
1-16: Verify NumberFormatLocale implementation and its impact on other localesThe changes look good and align with the PR objectives. However, it's important to verify a few things:
- The implementation of
NumberFormatLocaleinfuncoes.jsto ensure it correctly handles Brazilian number formatting.- The impact of these changes on other locales, ensuring that non-Brazilian numbers are not affected.
To assist with this verification, you can run the following script:
This script will help verify the implementation of
NumberFormatLocaleand its usage across the codebase, ensuring that it's correctly handling Brazilian numbers without affecting other locales.✅ Verification successful
NumberFormatLocale implementation verified and correctly handles other locales
The implementation of
NumberFormatLocaleinfuncoes.jsappropriately formats Brazilian numbers without affecting other locales. All usages across the codebase are consistent and adhere to the intended locale-specific logic.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify NumberFormatLocale implementation and its usage # Test 1: Check the implementation of NumberFormatLocale in funcoes.js echo "Checking NumberFormatLocale implementation:" ast-grep --lang javascript --pattern $'export function NumberFormatLocale($_) { $$$ }' # Test 2: Check for any conditional logic related to locales in NumberFormatLocale echo "Checking for locale-specific logic in NumberFormatLocale:" rg --type js "NumberFormatLocale.*Brazil" ./src # Test 3: Check for any other usages of NumberFormatLocale in the codebase echo "Checking for other usages of NumberFormatLocale:" rg --type js "NumberFormatLocale" ./srcLength of output: 5657
src/views/components/SendMessage.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom './funcoes.js' is correctly placed and aligns with the PR objectives of introducing number formatting functionality.
Line range hint
1-16: Verify consistency of number formatting across the applicationThe changes to introduce
NumberFormatLocalein this component are well-implemented. However, it's important to ensure that this formatting is consistently applied across the entire application wherever phone numbers are used.Please run the following script to check for other occurrences of phone number handling that might need similar updates:
Review the results to ensure that all relevant places are updated with the new
NumberFormatLocalefunction for consistency.✅ Verification successful
Consistency of phone number formatting is verified across the application.
All relevant components utilize
NumberFormatLocalefor handling phone numbers, ensuring consistent formatting throughout the codebase.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Search for potential phone number handling in other components and files # Test: Search for phone number-related variables or methods echo "Searching for phone number-related code:" rg --type js --type vue 'phone|number|telefone|número' src/ # Test: Search for potential formatting of phone numbers echo "\nSearching for potential phone number formatting:" rg --type js --type vue 'format.*phone|phone.*format' src/Length of output: 380
Script:
#!/bin/bash # Description: Search for potential phone number handling in .js and .vue files # Test: Search for phone number-related variables or methods echo "Searching for phone number-related code in .js and .vue files:" rg -g '*.js' -g '*.vue' 'phone|number|telefone|número' src/ # Test: Search for potential formatting of phone numbers echo "\nSearching for potential phone number formatting in .js and .vue files:" rg -g '*.js' -g '*.vue' 'format.*phone|phone.*format' src/Length of output: 13371
src/views/components/SendFile.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom './funcoes.js' is correctly added. This aligns with the PR objectives to implement number formatting based on locale.
21-21: Approve with suggestion: Verify locale-specific behavior in phone_id computed propertyThe implementation of
NumberFormatLocalein thephone_idcomputed property is correct and aligns with the PR objectives. It enhances WhatsApp number handling for both user and group types.However, consider adding a check for the 'Brazil' locale to ensure the formatting is only applied when necessary. This would align more closely with the PR objective of specifically handling Brazilian formatting rules.
To verify the implementation of
NumberFormatLocaleand its usage, please run the following script:This script will help us understand how
NumberFormatLocaleis implemented and used across the codebase, and whether there's any Brazil-specific logic that we might need to consider.✅ Verification successful
Verification Successful: Locale-specific behavior is correctly implemented
The implementation of
NumberFormatLocalein thephone_idcomputed property correctly handles the 'Brazil' locale as intended. The function ensures proper formatting for Brazilian phone numbers, and its usage across various components is consistent.🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash # Description: Verify the implementation and usage of NumberFormatLocale # Test 1: Check the implementation of NumberFormatLocale in funcoes.js echo "Checking NumberFormatLocale implementation:" ast-grep --lang javascript --pattern 'function NumberFormatLocale($_) { $$$ }' src/views/components/funcoes.js # Test 2: Verify the usage of NumberFormatLocale in other components echo "Checking NumberFormatLocale usage in other components:" rg --type js 'NumberFormatLocale\(' src/views/components/ # Test 3: Check for any locale-specific logic in the codebase echo "Checking for locale-specific logic:" rg --type js 'NumberFormatLocale.*Brazil' src/Length of output: 4314
src/views/components/SendPoll.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import statement for
NumberFormatLocalefrom./funcoes.jsis correctly implemented and aligns with the PR objectives to introduce number formatting for Brazilian rules.
Line range hint
1-18: Summary: Successfully implemented NumberFormatLocale for phone number formattingThe changes in this file successfully introduce the
NumberFormatLocalefunction for formatting phone numbers, which aligns with the PR objectives to enhance handling of WhatsApp numbers for Brazilian formatting rules. The implementation is correct and maintains the existing functionality while adding the new formatting feature.Key points:
- The
NumberFormatLocalefunction is properly imported.- The
phone_idcomputed property now applies the formatting function to the phone number.- The changes are non-breaking and integrate well with the existing code structure.
These modifications improve the flexibility of the component to handle different number formats based on locale settings.
src/views/components/SendImage.js (2)
1-1: LGTM: Import statement is correctly added.The import of
NumberFormatLocalefrom./funcoes.jsis properly placed and necessary for the changes in thephone_idcomputed property.
Line range hint
1-18: Consider updating tests and documentation.The changes to the
phone_idcomputed property improve number formatting without affecting the overall functionality of the component. However, it's important to ensure that these changes are reflected in any existing tests and documentation.Please run the following script to check for any existing tests related to this component:
If tests exist, please update them to account for the new number formatting logic. Also, consider updating any relevant documentation to reflect these changes.
src/views/components/SendVideo.js (2)
1-1: LGTM: Import statement for NumberFormatLocaleThe import of
NumberFormatLocalefrom './funcoes.js' is correctly added and aligns with the PR objectives to implement number formatting based on locale.
Line range hint
1-24: Summary: Successful implementation of number formatting in SendVideo componentThe changes in this file successfully implement the number formatting feature for WhatsApp numbers as described in the PR objectives. The
NumberFormatLocalefunction is imported and correctly applied in thephone_idcomputed property, ensuring that phone numbers are formatted according to the specified locale before being used.These changes enhance the flexibility of the component, allowing it to handle different number formats based on locale settings. The implementation is non-intrusive and maintains compatibility with existing functionality for other regions when no specific locale is set.
Overall, the modifications align well with the PR's goals and improve the component's ability to handle region-specific number formatting requirements.
src/internal/rest/send.go (8)
58-59: Consistent implementation of phone number formatting.The changes in this method are consistent with those in
SendText.Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
81-82: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
104-105: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
123-124: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
142-143: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
161-162: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
184-185: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.
203-204: Consistent implementation of phone number formatting.The changes in this method are consistent with those in previous methods.
Please refer to the comment on
SendTextregarding error handling forNumberFormatLocale.src/views/components/funcoes.js (1)
14-16: Ensure proper handling of international prefixesWhen adding the country code prefix
'55', make sure the number does not already include a'+'sign or other international prefixes. This prevents potential duplication or formatting issues.Consider enhancing the validation to handle different number formats and prefixes. Let me know if you'd like assistance in implementing this.
There was a problem hiding this comment.
Actionable comments posted: 40
🧹 Outside diff range and nitpick comments (29)
src/domains/newsletter/newsletter.go (1)
1-11: Consider separating newsletter functionality into a different PR.This newsletter implementation appears to be unrelated to the PR's stated objective of WhatsApp number formatting for Brazilian rules. Consider:
- Moving this newsletter functionality to a separate PR for better change isolation
- If this is indeed related to WhatsApp number formatting, update the implementation to clearly reflect that purpose
src/validations/newsletter_validation.go (1)
15-17: Consider providing more specific validation error messages.The current error wrapping is good, but consider providing more specific error messages to help API consumers better understand validation failures.
Example enhancement:
if err != nil { - return pkgError.ValidationError(err.Error()) + return pkgError.ValidationError(fmt.Sprintf("newsletter unfollow validation failed: %s", err.Error())) }src/internal/rest/newsletter.go (3)
4-6: Consider replacing panic-based error handling with proper HTTP error responses.The use of
utils.PanicIfNeededin a REST API context is not recommended as it can lead to unexpected service interruptions. Instead, consider implementing proper HTTP error handling that returns appropriate status codes and error messages to the client.Consider implementing a middleware for error handling and using it like this:
func (controller *Newsletter) Unfollow(c *fiber.Ctx) error { var request domainNewsletter.UnfollowRequest if err := c.BodyParser(&request); err != nil { return fiber.NewError(fiber.StatusBadRequest, "Invalid request body") } if err := controller.Service.Unfollow(c.UserContext(), request); err != nil { return fiber.NewError(fiber.StatusInternalServerError, "Failed to unfollow newsletter") } // ... rest of the code }
9-11: Add documentation comments for the Newsletter struct.Consider adding GoDoc comments to describe the purpose and responsibility of the Newsletter struct and its field.
+// Newsletter handles HTTP requests related to newsletter operations type Newsletter struct { + // Service provides newsletter-related business logic operations Service domainNewsletter.INewsletterService }
13-17: Add input validation and documentation for InitRestNewsletter.The initialization function should validate the service parameter and include documentation.
+// InitRestNewsletter registers newsletter-related routes and initializes the Newsletter controller func InitRestNewsletter(app *fiber.App, service domainNewsletter.INewsletterService) Newsletter { + if app == nil || service == nil { + panic("app and service parameters cannot be nil") + } rest := Newsletter{Service: service} app.Post("/newsletter/unfollow", rest.Unfollow) return rest }src/services/newsletter.go (2)
11-13: Consider adding GoDoc comments for the service struct.The struct is well-designed with proper dependency injection. Consider adding documentation comments to describe the service's purpose and responsibilities.
+// newsletterService handles WhatsApp newsletter-related operations type newsletterService struct { WaCli *whatsmeow.Client }
15-19: Consider adding GoDoc comments for the constructor.The constructor is well-implemented, following Go best practices with interface return type.
+// NewNewsletterService creates a new instance of the newsletter service +// with the provided WhatsApp client func NewNewsletterService(waCli *whatsmeow.Client) domainNewsletter.INewsletterService {src/views/components/generic/FormRecipient.js (1)
24-28: Consider adding tooltips for recipient types.The dropdown options could benefit from tooltips explaining the format requirements for each type.
Apply this enhancement:
this.recipientTypes = [ { value: window.TYPEUSER, text: 'Private Message', + tooltip: 'Enter a phone number with country code (e.g., +55123456789)' }, { value: window.TYPEGROUP, text: 'Group Message', + tooltip: 'Enter the WhatsApp group ID' }, { value: window.TYPENEWSLETTER, text: 'Newsletter', + tooltip: 'Enter the newsletter ID' } ];And update the template:
-<option v-for="type in recipientTypes" :value="type.value">{{ type.text }}</option> +<option + v-for="type in recipientTypes" + :value="type.value" + :title="type.tooltip"> + {{ type.text }} +</option>src/config/settings.go (1)
4-5: Consider moving HTTP handling to a dedicated packageThe addition of HTTP-related imports in the configuration package suggests a mixing of concerns. Configuration management should be separate from HTTP handling.
Consider:
- Moving the HTTP endpoint to a dedicated
apiorhandlerspackage- Using a configuration provider pattern that other packages can consume
src/validations/message_validation.go (2)
11-23: LGTM! Consider adding a comment for consistency.The implementation follows the established validation patterns and error handling conventions. The validation checks are appropriate for the use case.
Consider adding a function comment for consistency with Go's documentation standards:
+// ValidateMarkAsRead validates the MarkAsReadRequest ensuring required fields are present func ValidateMarkAsRead(ctx context.Context, request domainMessage.MarkAsReadRequest) error {
Line range hint
1-9: Remove duplicate import of the message domain package.The package is imported twice, once with and once without an alias. Since the code uses the aliased version, we should remove the non-aliased import.
package validations import ( "context" - "github.com/aldinokemal/go-whatsapp-web-multidevice/domains/message" domainMessage "github.com/aldinokemal/go-whatsapp-web-multidevice/domains/message" pkgError "github.com/aldinokemal/go-whatsapp-web-multidevice/pkg/error" validation "github.com/go-ozzo/ozzo-validation/v4" )src/go.mod (1)
Line range hint
1-59: Consider documenting significant version changes.Since there are multiple dependency updates, especially to core libraries like whatsmeow, consider adding a CHANGELOG.md entry or updating the existing one to document these changes.
src/views/components/MessageRevoke.js (1)
80-81: Consider adding input validation for Brazilian numbersSince FormRecipient handles phone input, ensure it validates Brazilian number formats (with/without '9' digit) when the locale is set to Brazil.
Consider adding these validations:
- For Brazilian numbers:
- Format: +55 DDD 9XXXXXXXX
- Format: +55 DDD XXXXXXXX (legacy)
- Display appropriate validation messages for Brazilian format when locale is set
src/views/components/MessageDelete.js (2)
57-57: Consider preserving user preferences in reset handler.The reset handler always defaults to TYPEUSER. Consider preserving the last used type if it aligns with your UX goals.
-this.type = window.TYPEUSER; +this.type = localStorage.getItem('lastUsedType') || window.TYPEUSER;
Line range hint
1-100: Consider implementing a locale strategy pattern for future scalability.While the current implementation works well for Brazilian numbers, as the application grows to support more locales, consider:
- Creating a dedicated locale strategy pattern for number formatting
- Moving locale-specific validation rules to separate configuration files
- Implementing a locale provider service for better separation of concerns
This would make it easier to add support for other countries' number formats in the future.
src/views/components/SendAudio.js (1)
Line range hint
37-46: Add error handling for invalid phone formatsThe submitApi method should handle potential errors from the backend when an invalid phone format is submitted.
Enhance error handling in the submitApi method:
async submitApi() { this.loading = true; try { let payload = new FormData(); payload.append("phone", this.phone_id) payload.append("audio", $("#file_audio")[0].files[0]) const response = await window.http.post(`/send/audio`, payload) this.handleReset(); return response.data.message; } catch (error) { if (error.response) { + // Handle specific phone format errors + if (error.response.data.code === 'INVALID_PHONE_FORMAT') { + throw new Error('Invalid phone number format for Brazil. Please use format: XX XXXXX-XXXX'); + } throw new Error(error.response.data.message); } throw new Error(error.message); }src/internal/rest/message.go (1)
101-118: Consider adding input validation.While the implementation follows the established pattern and correctly handles phone number sanitization, consider adding validation for:
- message_id parameter
- Required fields in the request body
func (controller *Message) MarkAsRead(c *fiber.Ctx) error { + messageID := c.Params("message_id") + if messageID == "" { + return c.Status(fiber.StatusBadRequest).JSON(utils.ResponseData{ + Status: 400, + Code: "INVALID_INPUT", + Message: "message_id is required", + }) + } + var request message.MarkAsReadRequest err := c.BodyParser(&request) utils.PanicIfNeeded(err) - request.MessageID = c.Params("message_id") + request.MessageID = messageID + if request.Phone == "" { + return c.Status(fiber.StatusBadRequest).JSON(utils.ResponseData{ + Status: 400, + Code: "INVALID_INPUT", + Message: "phone is required", + }) + } whatsapp.SanitizePhone(&request.Phone)src/views/components/AccountAvatar.js (1)
1-8: Consider using path aliases for imports.While the imports are correct, using relative paths like './funcoes.js' can become maintenance overhead if files are moved. Consider using path aliases (e.g., '@components/funcoes.js') for better maintainability.
src/views/components/MessageReact.js (1)
Line range hint
1-105: Consider adding error handling for invalid emojis.While the phone number formatting has been improved, the emoji input field lacks validation. Consider adding validation to ensure only valid emoji characters are submitted.
async submitApi() { this.loading = true; try { + if (!this.isValidEmoji(this.emoji)) { + throw new Error('Please enter a valid emoji'); + } const payload = {phone: this.phone_id, emoji: this.emoji} let response = await window.http.post(`/message/${this.message_id}/reaction`, payload) this.handleReset(); return response.data.message; } catch (error) {Add this helper method:
isValidEmoji(str) { const emojiRegex = /^(?:[\u2700-\u27bf]|(?:\ud83c[\udde6-\uddff]){2}|[\ud800-\udbff][\udc00-\udfff])$/; return emojiRegex.test(str); }src/views/components/MessageUpdate.js (1)
58-58: Add validation for window.TYPEUSER.Consider adding a validation check for the global variable.
handleReset() { + if (typeof window.TYPEUSER === 'undefined') { + console.warn('TYPEUSER is not defined'); + this.type = 'user'; // fallback + } else { this.type = window.TYPEUSER; + } this.phone = ''; this.message_id = ''; this.new_message = ''; this.loading = false; }src/views/components/SendMessage.js (1)
88-89: Consider adding input validation feedback.The FormRecipient component handles phone number input, but there's no visible validation feedback to users when they enter an invalid Brazilian number format (with/without digit '9').
Consider adding a validation message when the phone number doesn't match the expected format:
-<FormRecipient v-model:type="type" v-model:phone="phone"/> +<FormRecipient + v-model:type="type" + v-model:phone="phone" + @validation-error="handleValidationError" +/>src/views/components/NewsletterList.js (1)
74-116: Enhance template accessibility and user experience.While the template is well-structured, it could benefit from improved accessibility.
Consider these improvements:
- <div class="green card" @click="openModal" style="cursor: pointer"> + <div class="green card" + @click="openModal" + @keyup.enter="openModal" + role="button" + tabindex="0" + style="cursor: pointer"> <table class="ui celled table" id="account_newsletters_table"> + <caption class="sr-only">List of subscribed newsletters</caption>src/views/components/SendPoll.js (1)
Line range hint
37-52: Consider enhancing error handling and validation.The error handling in
submitApicould be improved:
- Add validation for minimum number of options (currently allows empty arrays)
- Validate max_vote against the number of options
- Add specific error handling for network issues vs. validation errors
Consider implementing these validations before the API call:
if (this.options.length < 2) { throw new Error('At least 2 options are required'); } if (this.max_vote > this.options.length) { throw new Error('Maximum votes cannot exceed number of options'); }src/views/components/GroupManageParticipants.js (2)
Line range hint
1-150: Implement Brazilian phone number validation for participants.Given the PR's objective to support Brazilian phone number formatting, this component should validate participant phone numbers when
NumberFormatLocaleis set to "Brazil".Consider adding validation in the
handleSubmitmethod:async handleSubmit() { try { + if (window.NumberFormatLocale === 'Brazil') { + for (const participant of this.participants) { + if (participant && !this.isValidBrazilianNumber(participant)) { + throw new Error(`Invalid Brazilian phone number format: ${participant}`); + } + } + } let response = await this.submitApi(); showSuccessInfo(response); $('#modalGroupAddParticipant').modal('hide'); } catch (err) { showErrorInfo(err); } }, +isValidBrazilianNumber(number) { + // Brazilian numbers: +55DDNNNNNNNNN + // where DD is area code (2 digits) + // N is the number (8 or 9 digits) + const cleanNumber = number.replace(/\D/g, ''); + return /^55\d{2}(\d{8}|\d{9})$/.test(cleanNumber); +}
Line range hint
1-150: Consider using FormRecipient component for participant inputs.The AI summary mentions a new
FormRecipientcomponent being used across other components for handling phone numbers. Consider using it here for consistency.This would provide:
- Consistent phone number formatting across the application
- Reusable validation logic
- Better maintainability
readme.md (1)
Line range hint
1-180: Document the WhatsApp number formatting feature.The main feature of this PR (WhatsApp number formatting for Brazilian rules) and its configuration options are not documented. Consider adding:
- A new section in the configuration documentation about the
NumberFormatLocalesetting- Usage examples for Brazilian number formatting
- Information about the
IgnoreExtractMediaandIgnoreExtractHistoryvariablesHere's a suggested addition to the documentation:
### Configuration Options + #### Number Formatting + - `NumberFormatLocale`: Defines the format of WhatsApp numbers for specific regions + - Default: "" (empty string, uses standard format) + - Supported values: "Brazil" (formats numbers according to Brazilian rules) + + #### Media & History Controls + - `IgnoreExtractMedia`: Disables media synchronization when set to true + - `IgnoreExtractHistory`: Disables chat history synchronization when set to true + + Example configuration for Brazilian numbers: + ```bash + ./whatsapp --number-format-locale="Brazil" + ```src/services/send.go (2)
512-519: Consider enhancing error context.The centralized upload logic is well-implemented. However, consider wrapping the error with additional context to aid debugging.
func (service serviceSend) uploadMedia(ctx context.Context, mediaType whatsmeow.MediaType, media []byte, recipient types.JID) (uploaded whatsmeow.UploadResponse, err error) { if recipient.Server == types.NewsletterServer { uploaded, err = service.WaCli.UploadNewsletter(ctx, media, mediaType) + if err != nil { + return uploaded, fmt.Errorf("failed to upload to newsletter server: %w", err) + } } else { uploaded, err = service.WaCli.Upload(ctx, media, mediaType) + if err != nil { + return uploaded, fmt.Errorf("failed to upload to regular server: %w", err) + } } - return uploaded, err + return uploaded, nil }
161-164: Standardize error messages across media types.The refactoring to use the centralized
uploadMediamethod is good, but the error messages are inconsistent:
- Image:
"failed to upload file: %v"- File:
"Failed to upload file: %v"- Video:
"Failed to upload file: %v"- Audio:
"Failed to upload audio: %v"Standardize the error messages across all media types. Consider using:
-fmt.Printf("failed to upload file: %v", err) +return response, fmt.Errorf("failed to upload %s: %w", mediaType, err)Also applies to: 213-216, 315-318, 452-456
docs/openapi.yaml (1)
229-241: Consider adding rate limiting documentation for newsletter endpoints.The newsletter endpoints and schemas are well-structured. However, consider documenting any rate limiting that may apply to these endpoints to prevent abuse.
Add rate limiting documentation using the following pattern:
parameters: - name: X-RateLimit-Limit in: header schema: type: integer description: Number of allowed requests in the current period - name: X-RateLimit-Remaining in: header schema: type: integer description: Number of remaining requests in the current periodAlso applies to: 1116-1149, 1450-1565
📜 Review details
Configuration used: CodeRabbit UI
Review profile: CHILL
⛔ Files ignored due to path filters (1)
src/go.sumis excluded by!**/*.sum
📒 Files selected for processing (38)
.gitignore(1 hunks)docs/openapi.yaml(6 hunks)readme.md(5 hunks)src/cmd/root.go(1 hunks)src/config/settings.go(2 hunks)src/domains/message/message.go(2 hunks)src/domains/newsletter/newsletter.go(1 hunks)src/domains/user/account.go(1 hunks)src/domains/user/user.go(1 hunks)src/go.mod(3 hunks)src/internal/rest/message.go(2 hunks)src/internal/rest/newsletter.go(1 hunks)src/internal/rest/user.go(2 hunks)src/pkg/whatsapp/whatsapp.go(3 hunks)src/services/message.go(2 hunks)src/services/newsletter.go(1 hunks)src/services/send.go(7 hunks)src/services/user.go(1 hunks)src/validations/message_validation.go(1 hunks)src/validations/newsletter_validation.go(1 hunks)src/views/components/AccountAvatar.js(4 hunks)src/views/components/AccountUserInfo.js(4 hunks)src/views/components/GroupManageParticipants.js(1 hunks)src/views/components/MessageDelete.js(3 hunks)src/views/components/MessageReact.js(4 hunks)src/views/components/MessageRevoke.js(3 hunks)src/views/components/MessageUpdate.js(4 hunks)src/views/components/NewsletterList.js(1 hunks)src/views/components/SendAudio.js(3 hunks)src/views/components/SendContact.js(4 hunks)src/views/components/SendFile.js(4 hunks)src/views/components/SendImage.js(3 hunks)src/views/components/SendLocation.js(4 hunks)src/views/components/SendMessage.js(4 hunks)src/views/components/SendPoll.js(4 hunks)src/views/components/SendVideo.js(4 hunks)src/views/components/generic/FormRecipient.js(1 hunks)src/views/index.html(6 hunks)
✅ Files skipped from review due to trivial changes (1)
- .gitignore
🚧 Files skipped from review as they are similar to previous changes (2)
- src/pkg/whatsapp/whatsapp.go
- src/views/components/AccountUserInfo.js
🧰 Additional context used
🪛 yamllint
docs/openapi.yaml
[error] 1687-1687: no new line character at the end of file
(new-line-at-end-of-file)
🪛 LanguageTool
readme.md
[style] ~151-~151: Using many exclamation marks might seem excessive (in this case: 27 exclamation marks for a text that’s 8381 characters long)
Context: ...---------------| | Homepage | 
(EN_EXCESSIVE_EXCLAMATION)
🪛 Biome
src/views/components/NewsletterList.js
[error] 70-70: isNaN is unsafe. It attempts a type coercion. Use Number.isNaN instead.
See the MDN documentation for more details.
Unsafe fix: Use Number.isNaN instead.
(lint/suspicious/noGlobalIsNan)
🔇 Additional comments (71)
src/domains/newsletter/newsletter.go (2)
1-4: LGTM! Clean package structure with necessary imports.
The package structure follows Go conventions, and imports are minimal and appropriate.
9-11:
Add validation and documentation to the request struct.
The struct would benefit from field validation and documentation. Additionally, there seems to be a disconnect between this implementation and the PR's stated objective of WhatsApp number formatting.
Consider these improvements:
+// UnfollowRequest represents the request parameters for unsubscribing from a newsletter.
type UnfollowRequest struct {
- NewsletterID string `json:"newsletter_id" form:"newsletter_id"`
+ // NewsletterID uniquely identifies the newsletter to unfollow.
+ NewsletterID string `json:"newsletter_id" form:"newsletter_id" binding:"required"`
}Let's verify if this file is in the correct context:
src/domains/user/user.go (1)
11-11: Verify if this change belongs in the current PR.
This PR's objective is to implement WhatsApp number formatting for Brazilian rules, but the addition of the MyListNewsletter method appears unrelated to this goal. Could you please clarify:
- The relationship between newsletter functionality and phone number formatting
- Whether this change should be in a separate PR to maintain focused scope
✅ Verification successful
Newsletter functionality is part of WhatsApp's API integration
The addition of MyListNewsletter method is actually justified in this PR as it's part of the WhatsApp API integration work. The evidence shows:
- The implementation in
services/user.godirectly calls WhatsApp client'sGetSubscribedNewsletters() - It's integrated with the same WhatsApp client (
whatsmeow.Client) that handles phone number formatting - The change is cohesive with other WhatsApp-related features in the codebase
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check if there are any phone number formatting related changes in the newsletter implementation
# Search for phone number formatting logic in newsletter-related files
rg -i "phone|number|format" -g "*newsletter*"
# Search for newsletter-related changes that might justify this addition
rg -i "newsletter" -g "*.go"
Length of output: 3365
src/validations/newsletter_validation.go (2)
1-8: LGTM! Clean package structure and imports.
The package declaration and imports are well-organized, using appropriate aliasing for domain and error packages.
10-20: Verify the integration with newsletter service.
This validation seems minimal. Let's verify how it's integrated with the newsletter service to ensure all necessary validations are covered.
✅ Verification successful
Let me gather more information about the validation and WhatsApp client integration.
Let me check the UnfollowRequest structure and WhatsApp validation implementation.
The validation is sufficient and properly integrated with WhatsApp validation
The current validation is appropriate because:
- It validates the required
NewsletterIDfield - The service layer performs additional WhatsApp-specific validation through
ValidateJidWithLoginwhich:- Ensures the client is logged in
- Verifies the newsletter ID is a valid WhatsApp JID
- Checks if the ID exists on WhatsApp when validation is enabled
The minimal structure of the validation aligns well with the single-field UnfollowRequest structure and the subsequent service-layer validations.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check newsletter service implementation and usage
# Expected: Find service implementation and API endpoints using this validation
# Check service implementation
echo "Checking newsletter service implementation..."
rg -A 10 "type NewsletterService" src/
# Check API endpoints
echo "Checking API endpoints..."
rg -A 5 "UnfollowNewsletter" src/
Length of output: 2142
Script:
#!/bin/bash
# Check WhatsApp client implementation and JID validation
echo "Checking WhatsApp JID validation..."
rg -A 5 "ValidateJidWithLogin" src/
# Check UnfollowRequest structure
echo "Checking UnfollowRequest definition..."
rg "type UnfollowRequest" src/
Length of output: 7182
Script:
#!/bin/bash
# Check UnfollowRequest structure details
echo "Checking UnfollowRequest structure details..."
rg -A 5 "type UnfollowRequest struct" src/
# Check WhatsApp validation implementation
echo "Checking WhatsApp validation implementation..."
rg -A 10 "func IsOnWhatsapp" src/
Length of output: 1149
src/services/newsletter.go (2)
1-9: LGTM! Well-structured package and imports.
The code follows good practices with clean package organization and proper domain separation.
21-32: 🛠️ Refactor suggestion
Consider enhancing error handling and adding context.
While the validation chain is good, the error handling could be improved:
- Consider wrapping errors with additional context
- Add logging for debugging purposes
- Consider potential race conditions if the WhatsApp client connection status changes between validation and execution
Here's a suggested improvement:
func (service newsletterService) Unfollow(ctx context.Context, request domainNewsletter.UnfollowRequest) (err error) {
if err = validations.ValidateUnfollowNewsletter(ctx, request); err != nil {
- return err
+ return fmt.Errorf("newsletter unfollow validation failed: %w", err)
}
JID, err := whatsapp.ValidateJidWithLogin(service.WaCli, request.NewsletterID)
if err != nil {
- return err
+ return fmt.Errorf("invalid newsletter JID %s: %w", request.NewsletterID, err)
}
- return service.WaCli.UnfollowNewsletter(JID)
+ if err := service.WaCli.UnfollowNewsletter(JID); err != nil {
+ return fmt.Errorf("failed to unfollow newsletter: %w", err)
+ }
+ return nil
}Let's verify the WhatsApp client connection handling in other parts of the code:
src/domains/user/account.go (2)
52-54: LGTM: Type definition follows established patterns
The new type definition:
- Follows the existing response structure patterns in the file
- Uses proper JSON tags
- Properly imports and uses the WhatsApp library type
types.NewsletterMetadata
52-54: Unrelated change to PR objectives
This addition of MyListNewsletterResponse type appears unrelated to the PR's stated objective of WhatsApp number formatting for Brazilian rules. Consider splitting unrelated changes into separate PRs to maintain clear change tracking and review focus.
src/domains/message/message.go (2)
6-6: LGTM! Interface method follows established patterns.
The MarkAsRead method signature is consistent with other methods in the interface, properly using context and following the same response pattern.
40-43: Consider adding validation tags and verify phone field handling.
While the struct definition is consistent with other request types, consider:
- Adding validation tags to ensure required fields (e.g.,
validate:"required") - Ensuring the phone field is properly formatted according to Brazilian rules when
NumberFormatLocaleis set to "Brazil"
Let's verify the validation implementation:
src/views/components/generic/FormRecipient.js (2)
1-12: LGTM: Component structure and props are well-defined.
The component declaration follows Vue.js best practices with proper prop validation.
1-52: Verify integration with other components.
This new component replaces existing phone input implementations across multiple components. We should verify that the Brazilian number formatting works consistently across all usages.
src/go.mod (1)
16-16: LGTM! Verify the dependency updates.
The dependency updates look good, particularly the WhatsApp library update which is relevant to the PR's number formatting changes.
Let's verify the changes don't introduce breaking changes:
Also applies to: 21-21, 23-24
✅ Verification successful
Based on the git history results, I can see that the dependency updates have been well-managed with proper documentation in commit messages. The recent updates (from commit 661a7ce) show minor version bumps with no breaking changes reported. The only TODO comment found is unrelated to dependencies.
Let me verify the specific sqlite3 version change by checking its changelog:
Let me check how sqlite3 is being used in the codebase to better assess the impact of this version update:
Let me check the actual usage of sqlite3 in the identified files:
SQLite dependency update is safe to proceed
The update from v1.14.23 to v1.14.24 of github.com/mattn/go-sqlite3 is a minor patch version that appears safe based on:
- SQLite is used only for WhatsApp session storage via whatsmeow's sqlstore
- Basic database operations with proper error handling in place
- No custom SQL queries or complex database operations that could be affected
- No reported database-related issues in recent git history
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Check for any breaking changes in the updated dependencies
# Test: Check git history for any dependency-related issues
git log --grep="dep\|dependency\|upgrade\|update" --since="3 months ago"
# Test: Look for any TODO/FIXME comments related to dependencies
rg -i "TODO|FIXME" -g "!vendor/*" -g "!node_modules/*"
Length of output: 2355
Script:
#!/bin/bash
# Check if there are any references to sqlite3 version or breaking changes
git log --grep="sqlite" --since="6 months ago"
# Look for any error handling or database-related issues
rg -i "sqlite.*err" -A 2 -B 2
Length of output: 78
Script:
#!/bin/bash
# Find files using sqlite3
rg -l "go-sqlite3|sqlite3"
# Check for database initialization and connection patterns
ast-grep --pattern 'sql.Open("sqlite3", $_)'
# Look for any database-related structs or interfaces
ast-grep --pattern 'type $_ struct {
$$$
*sql.$_ $_
$$$
}'
Length of output: 209
Script:
#!/bin/bash
# Check the sqlite3 usage in the identified files
rg -C 5 "sqlite3" src/pkg/whatsapp/whatsapp.go src/cmd/root.go
# Check if there are any database-related errors or issues reported
git log --grep="database\|sqlite\|sql" --since="3 months ago" -p
# Look for any database configuration or initialization
rg -C 3 "sql\.Open|database|\.db"
Length of output: 3253
src/internal/rest/user.go (2)
20-20: LGTM! Route registration follows consistent pattern.
The new endpoint registration is properly integrated with the existing routes and follows the established pattern.
85-95: Implementation looks good, but verify PR scope.
The newsletter endpoint implementation follows the codebase's patterns and best practices. However, this functionality appears unrelated to the PR's stated objective of "format whatsapp number for brazilian rules".
Let's verify if there are other files that implement the WhatsApp number formatting:
src/views/components/MessageRevoke.js (3)
1-2: LGTM: Clean component organization with proper imports
The addition of FormRecipient component and NumberFormatLocale function improves code organization by centralizing recipient handling and number formatting logic.
Also applies to: 6-8
58-58: LGTM: Consistent type reset
The handleReset method properly maintains consistency with the initial type value.
11-11: Verify number formatting behavior for non-Brazilian locales
The NumberFormatLocale function is now used for formatting phone_id, but we should ensure it maintains backward compatibility when NumberFormatLocale is not set to "Brazil".
Also applies to: 19-19
✅ Verification successful
Let me gather more information about the number formatting usage and locale handling.
Number formatting is safely handled for non-Brazilian locales
The implementation in funcoes.js shows that the NumberFormatLocale function properly handles non-Brazilian locales by returning the original number unchanged when getNumberFormatLocale() is not "Brazil". The function has a clear fallback behavior:
- For Brazil: Adds "55" prefix if missing and handles specific 13-digit format
- For all other locales: Returns the original number without modifications
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if NumberFormatLocale function handles empty locale gracefully
ast-grep --pattern 'function NumberFormatLocale($_) {
$$$
}'
# Check for any hardcoded Brazilian number formats
rg -i "brazil|brasileiro" --type js
Length of output: 993
Script:
#!/bin/bash
# Check how getNumberFormatLocale is implemented
ast-grep --pattern 'function getNumberFormatLocale() {
$$$
}'
# Check where NumberFormatLocale is used
rg "NumberFormatLocale\(" --type js -A 2
# Check for any other locale-related functions or configurations
rg "locale" --type js -i
Length of output: 6474
src/views/components/MessageDelete.js (4)
1-2: LGTM: Clean import statements for new functionality.
The imports align well with the PR objectives, bringing in the new number formatting functionality and the form component.
6-8: LGTM: Component registration follows Vue.js best practices.
The FormRecipient component is properly registered in the components object.
83-84: Verify FormRecipient's number validation for Brazilian format.
The FormRecipient component is now handling phone input validation. We should ensure it correctly implements Brazilian number formatting rules when NumberFormatLocale is set to "Brazil".
#!/bin/bash
# Check FormRecipient's validation logic
ast-grep --pattern 'FormRecipient = {
$$$
methods: {
$$$
validate($_) {
$$$
}
$$$
}
}'11-11: Verify the default type value and number formatting behavior.
While the changes look correct, we should ensure:
- The default type value matches the expected behavior for Brazilian numbers
- The NumberFormatLocale function handles empty phone numbers gracefully
Also applies to: 19-19
✅ Verification successful
Let me try to gather more specific information about the number formatting and type validation.
Based on the shell script results, I can now provide a conclusive response about the number formatting behavior and type values:
The type and number formatting implementation is correct and consistent
The verification shows that:
window.TYPEUSERis properly defined as "@s.whatsapp.net" inindex.htmland used consistently across all componentsNumberFormatLocalefunction infuncoes.jshandles Brazilian numbers correctly:- Checks configuration from
/api/config - Adds "55" prefix for Brazilian numbers when missing
- Empty phone numbers will pass through without modification
- Checks configuration from
The backend also validates and sanitizes the phone numbers through:
utils.NumberFormatLocale()for country-specific formattingwhatsapp.SanitizePhone()for additional validation
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check for any hardcoded phone number formats or validation
rg -A 3 "TYPEUSER|NumberFormatLocale" src/views/components/
# Look for related test cases
rg -l "test.*NumberFormatLocale" src/
Length of output: 222
Script:
#!/bin/bash
# Search for TYPEUSER constant definition and usage
rg "TYPEUSER|window\.TYPEUSER" -A 3
# Search for number formatting related functions
rg "NumberFormat|formatPhone|phoneFormat" -A 3
# Look for any phone validation logic
ast-grep --pattern 'function $_(phone) {
$$$
}'
# Check for any test files related to phone formatting
fd -e test.js -e spec.js
Length of output: 18811
src/views/components/SendAudio.js (3)
1-2: LGTM: Clean import statements
The imports are properly structured, bringing in the new NumberFormatLocale function and FormRecipient component needed for the Brazilian number formatting feature.
6-8: LGTM: Component registration
The FormRecipient component is properly registered in the components section.
12-12: Verify the global variable usage
The code relies on a global window.TYPEUSER variable. This could lead to potential issues if the variable is not properly initialized.
✅ Verification successful
Let me search for any initialization or definition of TYPEUSER in the codebase.
Global variable is properly initialized and used consistently
The window.TYPEUSER is properly initialized in src/views/index.html with the value "@s.whatsapp.net" and is used consistently across multiple components as a type identifier for private messages. This is a valid pattern in this codebase where the variable serves as a shared constant.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for window.TYPEUSER initialization
rg -l "window.TYPEUSER"
Length of output: 1370
Script:
#!/bin/bash
# Search for TYPEUSER definition or initialization
rg "TYPEUSER" -A 2 -B 2
Length of output: 9516
src/internal/rest/message.go (2)
21-21: LGTM! Route registration follows established patterns.
The new endpoint /message/:message_id/read is well-structured and consistent with existing message operation routes.
109-110: Verify error handling consistency across handlers.
Let's verify that error handling is consistent across all message handlers.
✅ Verification successful
Let me try a different approach to verify the error handling patterns.
Error handling is consistent across message handlers
After analyzing all Message controller methods, the error handling pattern is consistent throughout:
- All methods use
utils.PanicIfNeeded(err)for handling errors fromBodyParser - All methods use
utils.PanicIfNeeded(err)for handling service-level errors - All methods follow the same pattern of error checking and response structure
The error handling in the MarkAsRead method aligns perfectly with the established pattern in other message handlers.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for error handling patterns in message handlers
echo "Analyzing error handling patterns in message handlers..."
ast-grep --pattern 'func \(controller \*Message\) $_\(c \*fiber\.Ctx\) error {
$$$
utils.PanicIfNeeded\($_\)
$$$
}'
Length of output: 246
Script:
#!/bin/bash
# Search for all Message controller methods and their error handling
rg -U "func \(controller \*Message\).*fiber\.Ctx.*error.*\{[\s\S]*?\}" src/internal/rest/message.go
Length of output: 2478
src/views/components/MessageReact.js (4)
1-8: LGTM: Clean component organization.
The imports and component registration follow Vue.js best practices, promoting reusability through the FormRecipient component.
83-83: LGTM: Improved form field consistency.
The replacement of custom input fields with the FormRecipient component ensures consistent recipient input handling across the application.
20-20: Ensure NumberFormatLocale handles all edge cases.
The phone formatting now uses NumberFormatLocale which aligns with the PR's objective for Brazilian number formatting. However, we should verify that it gracefully handles:
- Empty or invalid phone numbers
- Non-Brazilian numbers when locale is not set
#!/bin/bash
# Find and examine NumberFormatLocale implementation and tests
ast-grep --pattern 'function NumberFormatLocale($_) {
$$$
}'11-11: Verify window.TYPEUSER availability.
The code now uses window.TYPEUSER instead of a hardcoded value, which is more maintainable. However, we should ensure this global variable is properly initialized.
Also applies to: 60-60
✅ Verification successful
window.TYPEUSER is properly initialized and widely used
The global variable window.TYPEUSER is initialized in src/views/index.html with the value "@s.whatsapp.net" and is consistently used across multiple components in the codebase. This is a valid implementation pattern for sharing a common WhatsApp-specific suffix across the application.
The verification shows:
- Initialization in
index.html:window.TYPEUSER = "@s.whatsapp.net" - Consistent usage across 13 different components including MessageReact.js
- Used both in type assignments and form configurations
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for window.TYPEUSER initialization
rg -l "window\.TYPEUSER\s*="
# Search for any TYPEUSER definitions
rg "TYPEUSER\s*=[^=]"
Length of output: 970
Script:
#!/bin/bash
# Search for TYPEUSER constant or variable declarations
rg -i "const.*TYPEUSER|var.*TYPEUSER|let.*TYPEUSER|window\['TYPEUSER'\]|window\.TYPEUSER"
# Search for any file that might define global constants
fd -e js -e ts "constants|config|types" --exec rg -l "TYPEUSER"
# Search for script tags in HTML files that might define global variables
fd -e html -e php . --exec rg -l "TYPEUSER"
Length of output: 2477
src/views/components/SendLocation.js (5)
6-8: LGTM: Component registration is properly structured.
The FormRecipient component is correctly registered in the components section.
65-65: LGTM: Reset handler properly resets the type.
The handleReset method correctly resets the type to window.TYPEUSER.
87-87: Verify FormRecipient component's phone number validation.
Since we're using FormRecipient for phone input, we should verify it implements proper validation for Brazilian phone numbers.
#!/bin/bash
# Description: Check FormRecipient component's validation logic
# Expected: Should find phone number validation implementation
fd FormRecipient.js --exec cat {} \; | rg -A 5 "validate.*phone"1-2: Verify the imported NumberFormatLocale function implementation.
The NumberFormatLocale import is crucial for Brazilian number formatting. Let's verify its implementation to ensure it handles all Brazilian number formats correctly.
#!/bin/bash
# Description: Verify NumberFormatLocale implementation in funcoes.js
# Expected: Function should handle Brazilian number formats with/without digit '9'
# Search for NumberFormatLocale implementation
ast-grep --pattern 'export function NumberFormatLocale($_) { $$$ }'11-11: Verify window.TYPEUSER global variable initialization.
The code relies on window.TYPEUSER which is a global variable. We should verify its initialization to prevent potential undefined errors.
Also applies to: 20-20
✅ Verification successful
Let me try another search strategy to find the initialization of this global variable.
The global variable window.TYPEUSER is properly initialized.
The variable is initialized in src/views/index.html before any component usage:
window.TYPEUSER = "@s.whatsapp.net";This initialization is consistent with the backend configuration in src/config/settings.go where the same value is defined as a constant:
WhatsappTypeUser = "@s.whatsapp.net"🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Description: Find where window.TYPEUSER is initialized
# Expected: Should find initialization before component usage
rg -A 3 "window.TYPEUSER\s*=\s*"
Length of output: 881
Script:
#!/bin/bash
# Search for TYPEUSER in all files, with more context
rg -i "TYPEUSER" -B 2 -A 2
# Also look for any window object property assignments
ast-grep --pattern 'window.$_ = $_'
Length of output: 12035
src/views/components/MessageUpdate.js (2)
1-8: LGTM! Clean component setup and imports.
The imports and component registration are well-structured, introducing the necessary dependencies for number formatting functionality.
84-85: Verify FormRecipient accessibility attributes.
While the component integration looks clean, ensure that the FormRecipient component maintains proper accessibility attributes for phone number input.
✅ Verification successful
The previous command didn't work because Vue components are typically defined differently. Let's search for the component definition and input elements to verify accessibility.
I found the FormRecipient component and saw some input elements with aria-labels, but let's examine its full content to ensure proper accessibility implementation.
FormRecipient component has proper accessibility attributes
The FormRecipient component implements proper accessibility attributes:
- Input fields have descriptive
aria-labelattributes ("wa identifier" and "whatsapp_id") - Form controls have associated
<label>elements - The select element is properly labeled with "Type"
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check if FormRecipient component has proper accessibility attributes
ast-grep --pattern 'class FormRecipient {
$$$
template: `
$$$
<input aria-label=$_
$$$
`
}'
Length of output: 111
Script:
#!/bin/bash
# Let's try to find the FormRecipient component file first
fd FormRecipient
# Then examine its contents for accessibility attributes
rg -A 5 -B 5 "<input" --type js
Length of output: 24260
Script:
#!/bin/bash
# Let's examine the FormRecipient component content
cat src/views/components/generic/FormRecipient.js
Length of output: 1429
src/views/components/SendContact.js (2)
1-8: LGTM: Clean component setup and registration.
The imports and component registration follow Vue.js best practices and align with the PR objectives for phone number formatting.
67-67: LGTM: Proper state reset implementation.
The handleReset method correctly resets all form fields, maintaining consistency with the initial state.
src/views/components/SendMessage.js (4)
1-2: LGTM: Clean import structure for new functionality.
The imports clearly separate the utility function (NumberFormatLocale) from the UI component (FormRecipient).
6-8: LGTM: Component registration follows Vue.js best practices.
The FormRecipient component is properly registered in the components object.
19-20: Verify number formatting behavior for non-Brazilian numbers.
While the NumberFormatLocale function is implemented for Brazilian numbers, we should ensure it gracefully handles other number formats when NumberFormatLocale is not set to "Brazil" in settings.
#!/bin/bash
# Check if NumberFormatLocale function has a default fallback
rg -A 5 "NumberFormatLocale.*=.*function" src/11-11: Ensure consistent type initialization.
The type is initialized and reset to window.TYPEUSER, which is good for consistency. However, we should verify that window.TYPEUSER is properly defined before the component loads.
Also applies to: 66-66
✅ Verification successful
Let me try a different search pattern to locate any references or definitions of TYPEUSER.
The initialization of window.TYPEUSER is properly defined and consistent.
The constant window.TYPEUSER is defined in src/views/index.html with the value "@s.whatsapp.net" before any components load. This initialization is used consistently across all components that need the type parameter for WhatsApp message addressing.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Check where TYPEUSER is defined and initialized
rg "TYPEUSER.*=.*" src/
Length of output: 48
Script:
#!/bin/bash
# Search for any occurrences of TYPEUSER in the codebase
rg "TYPEUSER" src/
# Also check for any potential type constants or enums
rg "type.*=.*" -A 2 src/
Length of output: 23024
src/views/components/SendFile.js (3)
1-8: LGTM! Clean component organization.
The addition of FormRecipient component and NumberFormatLocale import improves code modularity and reusability.
18-18: LGTM! Consistent type handling.
The use of window.TYPEUSER for both initialization and reset ensures consistent behavior throughout the component lifecycle.
Also applies to: 67-67
91-91: Verify FormRecipient component integration.
The FormRecipient component replaces the previous manual input fields, which is a good improvement for consistency. Let's verify its implementation.
#!/bin/bash
# Check FormRecipient component implementation
fd FormRecipient.js --exec cat {}
# Find other usages of FormRecipient to ensure consistent implementation
ast-grep --pattern 'import FormRecipient from "./generic/FormRecipient.js"'src/views/components/NewsletterList.js (1)
1-7: LGTM! Component structure follows Vue.js best practices.
The component is well-structured with a clear name and properly initialized data property.
src/views/components/SendPoll.js (5)
1-1: LGTM: Import statements align with PR objectives.
The addition of NumberFormatLocale and FormRecipient imports supports the PR's goal of implementing locale-specific phone number formatting.
Also applies to: 3-3
7-9: LGTM: Component registration follows Vue.js conventions.
The FormRecipient component is properly registered in the components section.
21-23: LGTM: Phone formatting aligns with locale requirements.
The computed property correctly uses NumberFormatLocale to format phone numbers according to locale-specific rules.
65-65: Same concern about window.TYPEUSER applies here.
13-13: Verify window.TYPEUSER initialization.
Using a global variable window.TYPEUSER could lead to runtime errors if not properly initialized. Ensure it's defined before the component loads.
✅ Verification successful
Let me check the initialization in the HTML file to verify if and how window.TYPEUSER is defined.
window.TYPEUSER is properly initialized
The global variable window.TYPEUSER is correctly defined in src/views/index.html with the value "@s.whatsapp.net" before any component loads, making it safe to use in the SendPoll component.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for window.TYPEUSER initialization
rg -l "window\.TYPEUSER\s*="
Length of output: 51
Script:
#!/bin/bash
# Check the content around window.TYPEUSER initialization
rg -C 3 "window\.TYPEUSER\s*=" src/views/index.html
Length of output: 253
src/views/components/SendImage.js (2)
1-8: LGTM! Well-structured component organization.
The addition of NumberFormatLocale and FormRecipient imports, along with proper component registration, follows Vue.js best practices and aligns with the PR's objective of improving number formatting.
94-95: LGTM! Good component composition.
The FormRecipient component integration with two-way binding improves code reusability and maintains a clean template structure.
src/views/components/SendVideo.js (2)
1-8: LGTM: Clean component setup
The imports and component registration are properly structured following Vue.js conventions.
100-101: LGTM: Clean form component integration
The FormRecipient component integration improves code reusability and maintains proper data binding.
src/services/message.go (2)
10-10: LGTM! Clean import addition.
The addition of the logrus logging package is appropriate for the new logging functionality.
31-55: LGTM! Well-integrated implementation.
The new MarkAsRead method follows the established patterns in the codebase and maintains consistency with other message operations. The implementation is clean and well-structured.
src/views/components/GroupManageParticipants.js (1)
13-13: Verify the impact of removing '@' separator in group_id.
The removal of the '@' separator from the group_id format appears to be a breaking change. This could affect existing group identifiers and API endpoints expecting the previous format.
src/cmd/root.go (1)
116-116: Review the newsletter service initialization.
The newsletter service integration follows the established pattern of service initialization and REST route setup. However, there are a few considerations:
- The service is initialized but there's no error handling for potential initialization failures
- The service is added at the application level without any configuration controls
Let's verify the newsletter service implementation:
Also applies to: 124-124
src/views/index.html (5)
89-96: LGTM! Newsletter section follows consistent UI patterns.
The new Newsletter section maintains the application's existing layout patterns and grid structure.
132-132: LGTM! Robust dynamic base URL configuration.
The dynamic base URL construction properly handles different protocols, hostnames, and optional ports, making it more flexible across environments.
162-162: LGTM! Component import follows established patterns.
The NewsletterList component import maintains consistency with other component imports.
189-189: LGTM! Component registration is consistent.
The NewsletterList component is properly registered following the application's component registration pattern.
109-111: Verify the impact of type constant changes.
The addition of "@" prefix to TYPEGROUP and TYPEUSER constants appears unrelated to the PR's objective of Brazilian number formatting. These changes could impact existing message handling functionality.
Let's verify the usage of these constants:
✅ Verification successful
Let me generate additional verification scripts to check if these constants are used in string concatenation or comparison operations that might be affected by the "@" prefix change.
Let me try one more search pattern to check for any existing string concatenations or template literals:
The type constant changes appear safe to proceed with
Based on the verification results:
- The constants are primarily used in form components for type selection and initialization
- Only one string concatenation found in
GroupManageParticipants.jswhich already expects the "@" prefix - No hardcoded old-format strings found in comparisons or validations
- The new
TYPENEWSLETTERconstant is properly integrated in the recipient type selection
The changes align with WhatsApp's standard type format and don't introduce compatibility issues with existing code.
🏁 Scripts executed
The following scripts were executed for the analysis:
Script:
#!/bin/bash
# Search for usages of TYPEGROUP and TYPEUSER to verify compatibility with new "@" prefix
echo "Searching for TYPEGROUP usage..."
rg "TYPEGROUP" --type js -A 2 -B 2
echo "Searching for TYPEUSER usage..."
rg "TYPEUSER" --type js -A 2 -B 2
Length of output: 10254
Script:
#!/bin/bash
# Search for string concatenation or comparison operations involving these constants
echo "Searching for string operations with TYPEGROUP..."
ast-grep --pattern 'window.TYPEGROUP + $_'
ast-grep --pattern '$_ + window.TYPEGROUP'
ast-grep --pattern '$_.includes(window.TYPEGROUP)'
ast-grep --pattern '$_.endsWith(window.TYPEGROUP)'
echo "Searching for string operations with TYPEUSER..."
ast-grep --pattern 'window.TYPEUSER + $_'
ast-grep --pattern '$_ + window.TYPEUSER'
ast-grep --pattern '$_.includes(window.TYPEUSER)'
ast-grep --pattern '$_.endsWith(window.TYPEUSER)'
# Search for any hardcoded strings that might match the old format
echo "Searching for hardcoded type strings..."
rg '"@g\.us"' --type js
rg '"@s\.whatsapp\.net"' --type js
rg '\.g\.us"' --type js
rg '\.s\.whatsapp\.net"' --type js
Length of output: 818
Script:
#!/bin/bash
# Search for template literals and string concatenations with these types
echo "Searching for string operations..."
ast-grep --pattern '`${$_}${window.TYPEGROUP}`'
ast-grep --pattern '`${$_}${window.TYPEUSER}`'
# Search for any references to these types in backend API calls
echo "Searching for API references..."
rg "type.*[:=].*['\"].*(@g\.us|@s\.whatsapp\.net)" --type js -A 2 -B 2
# Search for any validation or type checking
echo "Searching for type validation..."
rg "type.*===.*['\"].*(@g\.us|@s\.whatsapp\.net)" --type js
rg "type.*==.*['\"].*(@g\.us|@s\.whatsapp\.net)" --type js
Length of output: 633
readme.md (2)
115-116: LGTM: Feature list updates are accurate.
The changes correctly document the new features:
- Renamed "User My Groups" for consistency
- Added "User My Newsletter" feature
- Added "Read Message (DM)" feature
Also applies to: 131-131
151-151: LGTM: UI documentation is up-to-date.
The changes appropriately update the UI section with:
- New homepage image reflecting latest UI changes
- New "My Newsletter" screenshot
Also applies to: 173-173
🧰 Tools
🪛 LanguageTool
[style] ~151-~151: Using many exclamation marks might seem excessive (in this case: 27 exclamation marks for a text that’s 8381 characters long)
Context: ...---------------| | Homepage |
(EN_EXCESSIVE_EXCLAMATION)
src/services/send.go (1)
Line range hint 500-510: LGTM! Clean parameter update.
The change to ignore the unused context parameter using underscore is a good cleanup while maintaining the core functionality.
docs/openapi.yaml (1)
4-4: LGTM: Version bump and newsletter tag addition.
The version bump to 4.4.0 is appropriate given the addition of new newsletter-related features. The newsletter tag is well documented.
Also applies to: 19-20
| func (controller *Newsletter) Unfollow(c *fiber.Ctx) error { | ||
| var request domainNewsletter.UnfollowRequest | ||
| err := c.BodyParser(&request) | ||
| utils.PanicIfNeeded(err) | ||
|
|
||
| err = controller.Service.Unfollow(c.UserContext(), request) | ||
| utils.PanicIfNeeded(err) | ||
|
|
||
| return c.JSON(utils.ResponseData{ | ||
| Status: 200, | ||
| Code: "SUCCESS", | ||
| Message: "Success unfollow newsletter", | ||
| }) | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance request handling with validation, timeouts, and logging.
The current implementation could benefit from several improvements:
- Request validation beyond basic parsing
- Context timeout management
- Structured logging for monitoring and debugging
- Proper error handling instead of panics
Consider implementing these improvements:
func (controller *Newsletter) Unfollow(c *fiber.Ctx) error {
logger := c.Locals("logger").(log.Logger)
logger.Info("Processing unfollow request")
// Add timeout to context
ctx, cancel := context.WithTimeout(c.UserContext(), 10*time.Second)
defer cancel()
var request domainNewsletter.UnfollowRequest
if err := c.BodyParser(&request); err != nil {
logger.Error("Failed to parse request", "error", err)
return fiber.NewError(fiber.StatusBadRequest, "Invalid request format")
}
// Add request validation
if err := request.Validate(); err != nil {
logger.Error("Invalid request", "error", err)
return fiber.NewError(fiber.StatusBadRequest, err.Error())
}
if err := controller.Service.Unfollow(ctx, request); err != nil {
logger.Error("Failed to unfollow", "error", err)
return fiber.NewError(fiber.StatusInternalServerError, "Failed to process request")
}
logger.Info("Successfully unfollowed newsletter")
return c.JSON(utils.ResponseData{
Status: fiber.StatusOK,
Code: "SUCCESS",
Message: "Successfully unfollowed newsletter",
})
}| phone_id() { | ||
| return this.phone + this.type; | ||
| } |
There was a problem hiding this comment.
Implement number formatting for Brazilian locale.
The computed phone_id property should use the NumberFormatLocale function for Brazilian number formatting as per the PR objectives.
Apply this diff:
phone_id() {
- return this.phone + this.type;
+ const formattedPhone = this.formatPhoneNumber(this.phone);
+ return formattedPhone + this.type;
}Add the following method to handle the formatting:
methods: {
formatPhoneNumber(phone) {
// Import from funcoes.js
return NumberFormatLocale(phone);
}
}| ids := []types.MessageID{request.MessageID} | ||
| if err = service.WaCli.MarkRead(ids, time.Now(), dataWaRecipient, *service.WaCli.Store.ID); err != nil { | ||
| return response, err | ||
| } |
There was a problem hiding this comment.
🛠️ Refactor suggestion
Enhance error handling for MarkRead operation.
The error returned from MarkRead operation could be wrapped with more context to aid in debugging.
if err = service.WaCli.MarkRead(ids, time.Now(), dataWaRecipient, *service.WaCli.Store.ID); err != nil {
- return response, err
+ return response, fmt.Errorf("failed to mark message as read: %w", err)
}📝 Committable suggestion
‼️ IMPORTANT
Carefully review the code before committing. Ensure that it accurately replaces the highlighted code, contains no missing lines, and has no issues with indentation. Thoroughly test & benchmark the code to ensure it meets the requirements.
| ids := []types.MessageID{request.MessageID} | |
| if err = service.WaCli.MarkRead(ids, time.Now(), dataWaRecipient, *service.WaCli.Store.ID); err != nil { | |
| return response, err | |
| } | |
| ids := []types.MessageID{request.MessageID} | |
| if err = service.WaCli.MarkRead(ids, time.Now(), dataWaRecipient, *service.WaCli.Store.ID); err != nil { | |
| return response, fmt.Errorf("failed to mark message as read: %w", err) | |
| } |
| AddRequest: | ||
| type: string | ||
| example: null |
There was a problem hiding this comment.
Fix: Add newline at end of file.
The YAML file is missing a newline character at the end of the file.
Add a newline at the end of the file to comply with YAML standards and fix the yamllint error.
🧰 Tools
🪛 yamllint
[error] 1687-1687: no new line character at the end of file
(new-line-at-end-of-file)
Context
Adicionado variáveis para controle da sincronização de Mídias e Histórico (IgnoreExtractMedia e IgnoreExtractHistory) na pasta storages (útil quando não se deseja receber as mídias do telefone, utilizando apenas o envio da ferramenta);
Adicionado variavel "NumberFormatLocale" para definição do formato do número do whatsapp (Criado tratamento para a regra númerica do Brazil com e sem o digito 9
Criada função NumberFormatLocale (\src\views\components\funcoes.js) e NumberFormatLocale (\src\pkg\utils\general.go) para validar o formato por região. Adicionado tratamento apenas para o Brazil, mas basta adicionar outras localidades de acordo com as regras do número whatsapp da região.
Se informado no arquivo "\src\config\settings.go" para a variavel NumberFormatLocale = "" não interfere em nada no fluxo atual para outras regiões, se utilizado NumberFormatLocale = "Brazil" o tratamento para o Brazil é aplicado tanto no front quando via requisições na API