Version 1.68

Patch 1.68.33

Date: 12th Jan 2022

Bug fixed

Issue – The non-admin users of the customer were getting an error on the Converse home page
Fix– When a non-admin user of the customer was logging in on Salesforce and navigating to the Converse Home page, they were getting the following error:
‘Organization object does not have permission for field(s) Read’

In the checkIsSandbox() method of FMAUtility.cls the ‘Read’ access was being checked. And if the user was not having the ‘Read’ access, they were getting the said error on the Converse Home page.

To solve this issue, the checkIsSandbox() method of FMAUtility.cls the ‘Read’ access was removed.

Patch 1.68.30

Date: 23rd Dec 2021

Bug fixed
  1. Issue – The guest user of the customer was not able to send messages as the required license was not assigned but an org-wide license was present 

Fix- Guest users should be able to send messages even if the required license was not assigned but an org-wide license was present with a feature to send messages. However, the guest user of the customer was getting a license error and was not able to send messages even after the org-wide license was present. Messages were failing with an error- ‘You don’t seem to have the required license to send SMS or MMS’. 

One ‘if condition’ was present in the isFeatureAccessibleForUsers() method of LicenseManagerUtility, where only if any license was assigned to a user, the features of the org-wide license were getting checked. If any license was not assigned to the user then this ‘if condition’ was not pulling any features of the org-wide license.

To solve this issue, added condition if orgWideFeaturesSet is present, and if current userType is present in category field of License Type or category field is empty then add those features to the user.

  1. Issue – The non-admin users of the customer were getting a component error while they were navigating to the contact record.

Fix- In the getConversations method of LightningUtilityMessageNotification.helper, an undefined value was found, due to which this issue was occurring. 

To fix this issue, added one condition (not null and isValid()) for component.find method in helper class.

3. Issue – SMS-Magic mobile users were able to send SMS to leads even before obtaining their consent.

Fix- SMS-Magic mobile users were able to send SMS to leads even before obtaining their consent.

The customer had created a test user and provided the consent for testing purposes. The customer was using CustomConsentService class to validate consents. In SendSMSTriggerHelper.sendSMSBeforeTrigger(), the ConsentService.getConsentValidatedRecords() method was called to fail records on the basis of consent. The injection point was provided in this method. Messages were getting failed in the custom class and were returning to the list mobileApplicationSMSList in SendSMSTriggerHelper. As CustomConsentService was used, the list was sent and processed in a serialized form. In the process of serialization and deserialization, the reference was not followed and mobileApplicationSMSList was treated as a different list from smsList which is the main list. This main list was not getting updated.

To solve this issue, main list was updated as per the updated mobileApplicationSMSList in SendSMSTriggerHelper.sendSMSBeforeTrigger().

Patch 1.68.27

Date:  15th Nov 21

Bug fixed
  1. Issue: Customer was facing an error while creating consent record manually

Fix: The customer was getting an error ‘Invalid Phone Field’ while creating the consent record manually. The customer tried to create a consent record for the Case Role object and the phone field which the customer had selected was a lookup field that was fetching data from Accounts Object.

The phone field was added under the Message Object Configuration and the user was having all the required permissions still they were getting the same error.

Created a custom object named ‘Case Role’ and a lookup field that was fetching phone numbers from Accounts Object. Customer was getting an error ‘Invalid Phone Field’ while they were adding the object under Message Object Configuration and trying to create the consent.

The same issue was occurring for the standard objects as well.

 In the Phonenumber() method of the ComplianceService.cls class, the phone field was not getting resolved for lookup values.

Created similar configurations as mentioned in the description and tried creating consents manually. It created consent records successfully.

To Solve this issue Used the existing method SMSUtility.resolveFieldValue() to resolve the lookup values.

  1. Issue:  Many users were complaining that they were seeing SMS messages in their conversation view, while in ‘My Inbox’ that were not for them.

Fix:.Whenever a push topic subscription fails, An alternative method called get Latest Conversations After Given Time () in Conversation Service. cls from where the conversation records were fetched. This query did not have a filter for the owner.

 To solve this issue, added the Owner ID filter in the query while fetching conversation records.

  1. Issue:  All the mobile numbers were not showing when tried to send SMS from Send Bulk SMS Button

Fix: All the numbers were present in the conversation lightning component. However, the numbers were not showing when the user was trying to send SMS from the Send Bulk SMS Button. After debugging the issue,  it was analyzed that in LightningBulkSMSController the variable Allowable_Phone_Fields was initialized to 3. Hence it was showing only 3 phone numbers on the SendBulkSMS UI.

To solve this issue removed the Allowable_Phone_Fields variable from LightningBulkSMSController wherever it was used and populated the number of phone fields on SendBulkSMS UI which had been configured in the Message Object Configuration.

Patch: 1.68.26

Date:  3rd Nov 21

Bug fixed
  1. Issue: Customer was facing Component Error.

Fix: The user had reported the issue, which was not regular but intermittent, and occurred when the user opened any contact record. It couldn’t capture any logs as this was an intermittent issue.

The user was having permissions as well as licenses assigned, still was facing this issue.

Component Error occurred because push topic subscription was not successful for the affected user of the customer.

To solve this issue, added the Null check-in ‘ProcessMessages’ method of conversationComponentController.

Below is the link attached to the chatter and the component error that the customer was facing:

https://docs.google.com/spreadsheets/d 16EQVM_MDKgvsbB0uD9a94GZnO31518UjjzzJg6XxZgE/edit#gid=0

Patch: 1.68.23

Date:  13th Oct 21

Bug fixed
  1. Issue: The customer was not able to reply to his customers on WhatsApp during the 24hour session.

Fix: When a reply was sent from our mobile app to a WhatsApp message it was not coming through and giving the error ‘WhatsApp 24 hr active window is closed for this recipient’. You can send a message using a registered template only’. But a response from Salesforce and a reply were coming through.

For sources 1124, 1150, 1105, 1495, 4001, the 24-hour window was being validated by using the checkForMultiChannelSupport() method which was called from SendSMSTriggerHelper.cls in BEFORE context. From this method, the get QueryResults() method was called to query on SMS History Object to fetch incoming records within the last 24 hrs. Here ‘PrimaryLookupField’ was used in the ‘Where’ clause. There was an object lookup in case the SMS record contained any object lookup, like contact/lead or a conversation lookup.

In the case of orphan record, there was no lookup of any object on the SMS record so the conversation lookup field was being used in the ‘Where’ clause while querying. But in the previous context, there was no conversation lookup on an SMS record and that query was returning 0 rows. That’s why the valid duration was false.

To solve this issue instead of querying on the basis of any object lookup, querying on Phone number, Sender ID, and Channel code was done. So it was not affecting even if the Conversation lookup was empty.

Patch 1.68.18

Date:  31st Aug 21

Bug fixed
  1. Issue:  Automation Key Reference was wrong

Fix: The customer was facing an issue while sending automated messages to Prospects(lead). The process builder was set up for the 1st SMS message to new Prospect (Lead) records created. Any Lead created by the following user “Lender Site Guest User” was receiving an SMS.

Earlier, a customer was facing the following issue ‘Automation key reference was wrong’. This issue was resolved after sharing the settings assigned on the Converse App and App task.

The SMS history record was not getting created for guest users, the team was running a process in the queue in MessageAutomationHelper.queueablePostprocess() method, but in this method, a condition was applied, which was checked if it is Asynchronous or not. This condition was failing. That’s why it was not running in a queueable context.

To solve this issue, the check MessageUtility.isAsynchronousContext() was removed from MessageAutomationHelovper.queueablePostprocess().

Patch 1.68.17

Date:  19th Aug

Bug fixed
  1. Issue: Upgrade failed in Sandbox  as the customer was trying to upgrade from 1.55 to 1.68.14

Fix: Customer was trying to upgrade from 1.55 to 1.68.14 version and was receiving the below error: The error was seen on the Deployment status page: Error: Unexpected Error and the details were that the package installation failed. 1.68 Error Message: The post-install script failed.

The error that the customer received in the email was: The request to install package ‘SMS-Magic Converse Spring 2021’ was unsuccessful. None of the data or setup information in the Salesforce.com organization was affected. 
In AnalyticsControllerTest.cls the customer was ordering query results based on the Mobile Phone field of Contact Object. In the customer’s org the field which was encrypted was Salesforce limited and was used in ORDER BY clause in any query. The limited field was causing the installation of the package (v1.68.14) to fail in the customer’s org. The salesforce.com organization was affected

To solve this issue, the ORDER BY clause was removed in two queries referring to the MobilePhone field of Contact Object.

Patch 1.68.15

Date: 17th August 2021

Bug fixed
  1. Issue: The customer was receiving a component error on the case record page

Fix: A component error was appearing every time the customer was trying to send a message from a case record. The package was upgraded from 1.68.9 to 1.68.14 but the component error was still appearing.

Although the component error was appearing, the customer was able to send SMS but for this, they had to close 4 to 5 error windows. The customer was getting an error as shown in the image.

There was a reference to the attribute “slashTagBackUp” in the JS helper file. This attribute did not exist in the component which was causing the issue. 

To solve this issue, the reference of this attribute was removed from the JS helper file.

Component error on the case record page1
Component error on the case record page2
Component error on the case record page3

Patch 1.68.14

Date: 14th July 2021

Bug fixed
  1. Issue: Customer was not able to install SMS-Magic package on Salesforce essential

Fix
While trying to install the SMS-Magic package on Salesforce essential, the customer was getting an error message, ‘Your request to install package “SMS-Magic Converse Winter2021” was unsuccessful. None of the data or setup information in your salesforce.com organization was affected.’ 

In CampaignManageControllerTest.cls an operation was being run on a Product object which was a Salesforce-provided object. This was causing issues in Salesforce essentials as this object was not present in Salesforce essentials.

To solve this issue, the Product object was replaced with Contact & respective fields

  1. Issue: Error during an attempt to de-reference a null object

Fix
The user was creating a Consent record by calling the Invocable method from the process builder. For Phone type compliance, if the user does not add Sender ID in the process builder & tries to run that process builder, it was throwing an error in the error log object, “Attempt to dereference Null object”.

In the consent service, the Sender ID was being searched & if Sender ID was available then only the channel code was being checked.

In this case, Sender ID was always blank and that’s why it was pushing channel code as null while creating the consent.

To solve this issue, after Sender ID & channel code was checked, a check was added to see if the channel code is null. If yes, then ‘1’ was assigned as a default channel code.

Patch 1.68.12

Date:  17th June 2021

Bug fixed
  1. Issue: User was receiving a Sound Notification for Incoming SMS even when the notification was disabled from the SMS-Magic Converse settings

Fix
The default value of attribute ‘isIncomingVoicePermission’ in conversationView component was set to true. In controller.js the value of this attribute was set only if the corresponding flag value in global settings was set to true. Due to this, the value of the sound notification setting configured in the converse setting was properly populating in the Converse desk component. Thus even if it was set to false, the sound notification was getting played on incoming messages.

To solve this issue, the default value of the sound notification attribute in the conversation view was set to false. With this, the sound notification was not received on incoming messages.

  1. Issue: Admin was not able to access the SMS-Magic Converse Settings

Fix
The customer was not able to access the Converse Settings and was receiving an error, “You do not have a License which provides access to this feature.” in spite of having the required license. 

The code was checking for the profile name of the logged-in user to be “System Administrator”. Thus even if the user had admin privileges, as the profile was not “System Administrator”, the user was not able to access the Converse settings.

To solve this issue, the unnecessary “System Administrator” profile check was removed.

Was This Article Helpful?