DLRS dependency on apex-common - Platform Encryption

[cropredyHelix]

DLRS depends on apex-common

apex-common has several test methods that use LIKE or ORDER BY on potentially encryptable OOTB standard fields:

• Account.Name
• Opportunity.Name

see issues:

• https://github.com/financialforcedev/fflib-apex-common/issues/194
• https://github.com/financialforcedev/fflib-apex-common/issues/180
• https://github.com/financialforcedev/fflib-apex-common/issues/237

This would make DLRS uninstallable/unupgradeable in orgs that implemented Platform Encryption on those fields

[afawcett]

Thanks @cropredyHelix . Can you confirm if this is indeed and issue you have hit?

[cropredyHelix]

Andrew - Thank you for following up.

YES, this is confirmed.

• I took a Trailhead DE org,
• enabled Encryption on Opportunity.Name (couldn't enable encryption on Account.Name because DreamHouse app prevents that)
• installed DLRS 2.11
• received error as shown below

I will note I had a similar discussion on this topic with Doug Ayers and his Mass Action Scheduler package. You can read about that here.

[afawcett]

@cropredyHelix thanks so much for sharing further background.

[cropredyHelix]

No problem; as I stated to Doug Ayers, I've come to the conclusion that ISVs or open source GitHub repos should enable Shield encryption for every OOTB standard field that is encryptable and then test their package/repo. This will help avoid testmethods shortcuts such as using ORDER BY or LIKE on encryptable fields; it also helps sort out any Dynamic SOQL issues that could occur at runtime.

Topic for an andyinthecloud blog post?

On Thu, Jan 2, 2020 at 1:18 PM Andrew Fawcett [email protected] wrote:

@cropredyHelix https://github.com/cropredyHelix thanks so much for sharing further background.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/afawcett/declarative-lookup-rollup-summaries/issues/865?email_source=notifications&email_token=AGDWAA6JEPZM7DFYT7WTFCDQ3ZKZZA5CNFSM4IYEDLAKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOEH7OOQI#issuecomment-570353473, or unsubscribe https://github.com/notifications/unsubscribe-auth/AGDWAAZXAG3GBVX6OE67VGLQ3ZKZZANCNFSM4IYEDLAA .

-- Eric Kintzer Salesforce Architect

101 S. Ellsworth Ave, Suite 350, San Mateo, CA 94401 650 533 5619 (m) www.helix.com | We're hiring https://www.helix.com/careers

-- CONFIDENTIALITY NOTICE This e-mail and any attachments contain confidential information from Helix and are for the sole use of the intended recipients. This e-mail may also contain legally privileged communications or work product. If you have received this e-mail in error, please notify the sender by reply e-mail and delete the message. Any disclosure, copying, distribution, or use of this communication by someone other than the intended recipient is prohibited.

[quintencls]

@afawcett We are experiencing the same issue on Contact Name. Do you know if anything happened in relation to encryption support the past year? Thanks a lot!

This is the specific error we see for LastName on Contact:

Apex Class: ConvertRecordsToCSVQueueableTest, line 67, column 42: field 'LastName' can not be grouped in a query

[aheber]

I'm not sure I understand the issue here. To help prioritize this can we understand why the test classes need to pass in an org that has encryption enabled on these fields?

Test classes don't need to be executed in installed orgs, only in packaging orgs. Maybe I'm lost on something here?

If we can add some details then we can review the impact. Thanks!

[oakyraja]

@aheber I just faced the exact same issue. We are using shield encryption and opportunity name is encrypted. Thus the installation failed.

When we are installing the dlrs package, all the test classes in the package are run in the installing org.

Since SOQL on deterministic encrypted fields under the WHERE filter statement is not allowed with operators LIKE is not supported. Please check https://developer.salesforce.com/docs/atlas.en-us.securityImplGuide.meta/securityImplGuide/security_pe_deterministic_considerations.htm for all considerations.

Moreover , if the encryption is probabilistic, then the field cannot be used in WHERE Clause.

So, i would suggest to write test classes with standard fields which are not available for encryption to avoid this SHIELD encryption issue.

This should be impacting multiple users. Please take this change request on priority.

We are waiting for this fix as well.

[oakyraja]

@afawcett , this is a quick tune up of the test classes. Can we get this in the next update/release ?

[aheber]

I have this on my backlog to look at. I don't know if it is execution of the test classes as much as compilation, the platform is smart enough to reject that Apex because it is incompatible with the org.

I don't think it is a heavy task but I haven't finished research on the impact to make the change.

In theory the tests need to be adjusted to use fields that can't be added to shield encryption so anyone is welcome to raise a PR before any of the rest of the team can get to it.

[aheber]

@oakyraja, I took a look at this tonight. The changes appear to be isolated and fairly simple. I'll try and get a PR submitted shortly. I expect this will be included in 2.19 which doesn't have a planned release date at this time.

[aheber]

I've submitted a PR to be reviewed by the team.

I've added a not on the PR but I'll restate here.

I believe that with these changes you'll be able to install now. You'll still have some limitations on what rollups can be configured, fundamental limitations related to encrypted fields. (Not in WHERE or ORDER BY in most cases). Hopefully this gives you enough freedom to experiment and find configurations that work for your needs.

Once this merges in it should be in the next release that is likely a few months away at the soonest.

[oakyraja]

That's great news! Thats for the quick action on the Test Class changes. We can wait for the next release and we do understand the limitations with the Encryption fields and DLRS

Thanks @aheber

[aheber]

I'm going to close this, these fixes should have been in the last few versions. If anyone has additional problems please open a new issue and we can look further.