W-14578178 Fix Contact Address Override Functionality #7250
Conversation
Added changes in Addresses.cls and ContactAdapter.cls to fix Contact Address Override Functionality
Assertions added in 'updatedUndeliverableDefaultAddressDoesNotCauseMultipleOverrideUpdates' method
| // if found a match | ||
| if (contactAddressHasAddressMatch(existingAddressFromContact)) { | ||
| // Check if the contact has Address Override enabled | ||
| if (contact.is_Address_Override__c == true) { |
There was a problem hiding this comment.
We typically capitalize the first character of a field name (not counting the namespace of course).
| if (contact.is_Address_Override__c == true) { | |
| if (contact.Is_Address_Override__c == true) { |
| @@ -911,14 +911,16 @@ public with sharing class ADDR_Addresses_TEST { | |||
| Test.stopTest(); | |||
|
|
|||
| Address__c updatedAddress = [SELECT Default_Address__c, Undeliverable__c FROM Address__c WHERE Id = :overrideAddressToCreate.Id]; | |||
| Contact updatedContact = [SELECT Undeliverable_Address__c FROM Contact WHERE Id = :contact.Id]; | |||
| Contact updatedContact = [SELECT Undeliverable_Address__c,is_Address_Override__c FROM Contact WHERE Id = :contact.Id]; | |||
There was a problem hiding this comment.
Same here
| Contact updatedContact = [SELECT Undeliverable_Address__c,is_Address_Override__c FROM Contact WHERE Id = :contact.Id]; | |
| Contact updatedContact = [SELECT Undeliverable_Address__c, Is_Address_Override__c FROM Contact WHERE Id = :contact.Id]; |
This reverts commit c45698c.
Changes added in 'updatedUndeliverableAddressShouldSyncToAccountAndHouseholdContactOverrides' test method
…hod of ContactAdapter.cls
| **/__mocks__/** |
There was a problem hiding this comment.
Did you mean to check in this file?
| } | ||
|
|
||
| // Check if the contact has Address Override enabled | ||
| if (contact.Is_Address_Override__c == true) { |
There was a problem hiding this comment.
Is there a possibility that this logic will create multiple Address records for the same address over time, basically each time the Contact record is edited to change any field value? The original logic appears to have first looked for a matching address before it inserted a new address. The new changes move that check to after the logic to insert a new address.
There was a problem hiding this comment.
Thank you for bringing this up. The reason we're proceeding to create a new address when Address Override is enabled, without checking for an existing address, is to ensure that the contact’s address remains completely independent of any household address updates.
By generating a new address for each contact with Address Override enabled, we maintain distinct address records for the contact, which aligns with the intended behavior of keeping contact addresses separate from household changes. This prevents any potential conflicts between the contact’s address and the household’s address. For contacts without Address Override, we continue to match existing addresses before inserting new ones to ensure consistency.
There was a problem hiding this comment.
That makes sense. My question though is whether every tiny change to the Contact will create a new Address record. To test:
- Create a Contact with an Address and the Override set
- Confirm that there is one Address record linked to that Contact
- Edit the Contact again to add or change the value in Title
- Is another Address record created for the same exact address?
If the answer to that last bullet is yes, we'll need to fix that. Let me know what you find.
There was a problem hiding this comment.
@force2b, I have tested the scenario where non-address fields like Title are updated, and I confirmed that no new address records are created in such cases. The new address creation is only triggered by changes in address-related fields, as intended.
There was a problem hiding this comment.
Thank you for testing and confirming.
| @@ -197,7 +197,7 @@ private with sharing class ACCT_AccountMerge_TEST { | |||
| System.assertEquals(cHH * cCon, listCon.size()); | |||
|
|
|||
| // verify Addresses are merged | |||
| System.assertEquals(cHH + 1, [SELECT count() FROM Address__c]); | |||
| System.assertEquals(cHH * 2, [SELECT count() FROM Address__c]); | |||
There was a problem hiding this comment.
Why check for double (2x) the number of records here; which I think would be 6 address records? The previous assert was checking for only 4 records. Does the new override cause more address records to be created?
There was a problem hiding this comment.
@force2b thank you for your feedback. The assert now checks for double the number of address records because the new Address Override functionality creates a separate address for each contact with the override enabled. Previously, the contacts shared the household address, resulting in fewer records. With the override, each contact now gets its own distinct address, which correctly leads to a higher count. This behavior aligns with the goal of maintaining independent addresses for contacts with Address Override enabled.
|
@force2b thank you for approving the changes, could you please merge this PR. |
force2b
deleted the
feature/254__W-14578178-fix-contact-address-override-functionality
branch
Critical Changes
GUS W-14578178
To skip the update for contacts with address override, chages made in :
Changes
Issues Closed
Community Ideas Delivered
Features Intended for Future Release
Features for Elevate Customers
New Metadata
Deleted Metadata