Apex Code Development You need to sign in to do that
Don't have an account?
Ab Impact analysis , steps to follow for "Enforce Access Modifiers on Apex Properties in Lightning Component Markup (Update, Postponed)"
Hello,
For the release update "Enforce Access Modifiers on Apex Properties in Lightning Component Markup"
I would like to know the steps to follow for analysis and possible workaround if possible.
links for reference :
Link 1 (https://help.salesforce.com/articleView?id=release-notes.rn_lc_enforce_prop_modifiers_cruc.htm&type=5&release=230)
Link 2 (https://help.salesforce.com/articleView?id=release-notes.rn_lc_crucs.htm&release=228&type=5)
Thank you for advise
For the release update "Enforce Access Modifiers on Apex Properties in Lightning Component Markup"
I would like to know the steps to follow for analysis and possible workaround if possible.
links for reference :
Link 1 (https://help.salesforce.com/articleView?id=release-notes.rn_lc_enforce_prop_modifiers_cruc.htm&type=5&release=230)
Link 2 (https://help.salesforce.com/articleView?id=release-notes.rn_lc_crucs.htm&release=228&type=5)
Thank you for advise
I'm working on the same critical update. Here's my approach:
1. Determine if there are any custom Apex Classes that have private methods that could be used with a Lightning Component.
To do this, I could open each custom Apex Class one by one, but instead I used an IDE (in my case, IntelliJ with Illuminated Cloud) to search my org's custom Apex Classes for the word Private. Then I evaluated each result to decide whether it could be called by a Lightning Component. None of the results fell into that category. They were all private variables or private methods used within the Apex Class.
If any had fallen into that category, then I would've updated the Class in a sandbox (as described in your Link 1), enabled the critical update, tested and, after I was confident of the change, deployed to Production.
2. See if there are any managed Installed Packages that could be impacted.
In my thinking, these are trickier since for managed packages we can't see the Apex Class code. My approach is to see what managed Installed Packages contain Lightning Components and Apex Classes, then look on AppExchange. On AppExchange I'll be looking at 2 things: (1) how does the latest release date for the package compare to the last modified date in my org; and (2) are there any comments by the vendor or feedback/reviews from other customers about this critical update. Depending on what I learn, I may need to update some Installed Packages.
Hope this helps!
B Babow
All Answers
Disabled Ref Id and New Threading Behavior for Email-To-Case
https://help.salesforce.com/articleView?id=000355168&language=en_US&mode=1&type=1
The Winter '21 release brings a new, more secure, threading behavior for Email-to-Case. With the new behavior, incoming emails are matched to cases with their header information, rather than through a Ref ID from the subject or body. Outbound emails made after the update no longer contain a Ref ID.
Starting with the Winter ‘21 release, all new orgs default to the new threading behavior and Email-to-Case no longer supports string-based threading. The Release Update, Disable Ref ID and Transition to New Email Threading Behavior, lets admins of existing orgs turn the new threading behavior on or off until the update is auto-enforced with the Summer ’21 release.
Existing orgs continue to to use RefID as the main criterion for matching emails until admins enable the new threading behavior. When the new threading behavior is enabled, Email-to-Case won’t insert Ref ID for outbound emails, and ignores the Ref ID from incoming emails for matching.
Resolution
+++++++++++++++
The email headers used for the new threading behavior are Message-ID, In-Reply-To, & References.
The EMailMessage entity saves a unique Message-ID for each incoming and outbound email. Since the Summer ’20 release, the Message-ID for all standard outbound Email-to-Case emails are automatically saved. Admins only need to turn on the new threading behavior to properly match new emails to their case.
For incoming emails, Email-To-Case evaluates the In-Reply-To header, which also contains the Message-ID of the previous outgoing email. If In-Reply-To finds a matching EMailMessage entity, Email-to-Case uses the related Case to link the new email.
If the In-Reply-To header doesn’t return a match, Email-To-Case attempts to match the EMailMessage entity with a References header, which is a list Message-ID from previous emails in that thread. If Email-to-Case finds one or more matches, it links the new email to the related Case from the most recent EMailMessage entity. A new case is created if there’s no match on the References header.
Starting with the Winter '21 release, Email-to-Case saves the required threading headers by default.
When existing orgs are enabling the new Threading behavior via the Release Update, remember the following considerations and limitations:
Make sure the emails sent to Salesforce contain the correct required Threading headers for matching.
Apex method “getCaseIdFromEmailThreadId” is deprecated and replaced with a new method “getCaseIdFromEmailHeaders”.
If you turn the update off, incoming responses without Ref ID will not link to an existing case and a new one will be created.
Update any existing custom code to ensure it no longer uses the Ref ID.
Incoming responses to emails that were sent before Summer ‘20 will not match correctly.
For incoming emails with more than one routing address in the TO field, or with any in the CC field, Email-to-Case processes the same email independently, which can result in multiple new cases.
While it’s not recommended since this update to email threading increases security for your org, the Messaging.InboundEmailHandler apex interface lets orgs further customize email matching.
Let me know if it helps you and close your query by marking it as the Best answer so that it can help others in the future.
Thanks.
my question is different
I'm working on the same critical update. Here's my approach:
1. Determine if there are any custom Apex Classes that have private methods that could be used with a Lightning Component.
To do this, I could open each custom Apex Class one by one, but instead I used an IDE (in my case, IntelliJ with Illuminated Cloud) to search my org's custom Apex Classes for the word Private. Then I evaluated each result to decide whether it could be called by a Lightning Component. None of the results fell into that category. They were all private variables or private methods used within the Apex Class.
If any had fallen into that category, then I would've updated the Class in a sandbox (as described in your Link 1), enabled the critical update, tested and, after I was confident of the change, deployed to Production.
2. See if there are any managed Installed Packages that could be impacted.
In my thinking, these are trickier since for managed packages we can't see the Apex Class code. My approach is to see what managed Installed Packages contain Lightning Components and Apex Classes, then look on AppExchange. On AppExchange I'll be looking at 2 things: (1) how does the latest release date for the package compare to the last modified date in my org; and (2) are there any comments by the vendor or feedback/reviews from other customers about this critical update. Depending on what I learn, I may need to update some Installed Packages.
Hope this helps!
B Babow