SFDO-Community/declarative-lookup-rollup-summaries

Summer 19-Invalid field MasterRecordId for Case SobjectException due version 42

aparnagkrishna opened this issue ยท 38 comments

After Summer 19 release, Case object is meragble and RollupService Class throwing below exception

System.SObjectException: Invalid field MasterRecordId for Case Class.dlrs.RollupService.handleRollups: line 727,

https://releasenotes.docs.salesforce.com/en-us/summer19/release-notes/rn_cases_merge.htm

If we update the salesforce api version on RollupService to 46 this will be fixed

Hi Aparna! I've come across this error too - how did you update the API ? when I tried it wouldn't let me save it
image

Hi Aparna! I've come across this error too - how did you update the API ? when I tried it wouldn't let me save it
image

it needs to be updated on the package. I have already put a fix and waiting for @afawcett to merge

Thank you @aparnagkrishna .

@afawcett hope you can do that soon because it will a real problem when the summer release will be deployed on production... Thank you for the great app!!

Mmm, maybe I do not understand, but why if you run something with version 42, does a field of version 46 show up?

API 46 isn't available in Production yet obviously so it's a bit of an issue to roll out a 2.12 with that changed.

@aparnagkrishna are you getting the error only when you attempt to Merge a Case? Or anytime a Case is created or edited? Or when a Parent Record is getting merged?

@JimBTek I am seeing this error too in all of my sandboxes. It's happening whenever I try to create or edit a case.

This issue started occurring in a sandbox since Summer '19 went in. Despite there being no DLRS configuration entries in this sandbox, the reference to dlrs.RollupService.triggerHandler(); from the Trigger will throw the above error.

@deckblad Any way around this? I'm trying to work on other features for cases, but this error is preventing me from doing anything.

Can you try managing the child triggers for DLRS and removing the one for Cases similar to:
image

Or perhaps re-deploying the child trigger on Case with "Deploy code to support record merging?"

image

@JimBTek That worked. I deleted the dlrs Case Trigger and could create a case. I can just do that in sandboxes.

Thanks!

@afawcett @JimBTek I am getting the error any time a case is being edited/deleted in my Sandbox. If I remove the triggers for the Case object, the issue goes away. If I try to redeploy the triggers with "Deploy code to support record merging?" selected, I still get the error.

For now, I will delete the triggers in SB

We are also getting this error any time our custom objects that do roll ups to the case are fired. Causing a huge issue for us. Can't do any of our product testing in dev or staging.

We really need this fixed but in the meanwhile I've deactivated (rather than deleted) the dlrs_CaseTrigger.

@kbuckles-sfdc thanks for trying that. At least anyone finding this issue has a temporary workaround.

@rlandingham @Stefanie9786 If it's super critical, you can try uninstalling the managed package and install the files unmanaged, and try the workaround of updating the API version for RollupService.cls as shown in the proposed pull request #819. Make sure to back up your config first.

@horzel

With Salesforce summer 19 release, Case object got merge properties, Which means when we run rollupservice.cls (currently on API 42) case object describe ismergable() method returns true and try to get the MasterRecordId of case object. Case object received its merge status on recent release only(which is API 46). And API version 42 is not aware of MasterRecordId against Case(which is a merge related field) which is causing the RollupService to fail on l:741

It is very similar to quote object is not available on API 4.

If you are planning to deloy the unmanaged package and change the version, please make sure to deploy the changeset production only after summer 19 release on production instances

Can we please have confirmation if this managed package will be updated or it's encouraged to go to the unmanaged package path for the users? Thanks.

I am looking at updating the managed package now. The tricky part is this API version is only applicable to "some" sandboxes at present. So i need to look at a different fix. I'm looking at it now to see if i can create a patch release of the latest version.

@qswh the unmanaged package route is really just a temporary fix for Sandboxes. A better temporary fix is to just disable the Cases DLRS Trigger, but if you need it on for your testing you may need to use the unmanaged package for now. I use DLRS in several Production orgs for clients and am confident this will get resolved before.

I am just helping with the issues and wiki, but I know this is on Andy's radar and there is one proposed fix pending review to just bump the API to 46 in the managed package. This will work once Production has v46 on all pods, and may be a solution to create a 2.12 version, but a Pull Request with a fix beyond just bumping the API to 46 that is compatible with v45 and v46 would be very helpful to get from the community. Otherwise you will have to wait for Andy to have time to address this. Keep in mind this is a volunteer effort. I have also made an Apex manager at Salesforce aware of this issue thread.

I am also discussing with the Apex team as this sounds like a bug to me. Meanwhile though i am reviewing a possible fix...

@aparnagkrishna

But if you do a describe call, and your code is running in API 42, why does it return ismergable?

In release 42 cases are not mergable!

It is the same as that if somebody has a JavaScript button with API 13, a triggered process builder using record type developer name fails, as they only became available in API 15

@horzel in testing it does appear that isMergeable() may not care what API version you set in your class, at least in Summer '19. So there may be a platform bug. Either way it looks like a patch may be incoming soon for DLRS. Hang tight!

Can we please have confirmation if this managed package will be updated or it's encouraged to go to the unmanaged package path for the users? Thanks.

It depends on your implementation. Since this affects only sandboxes at this moment, you should be good to go with disabling the rollups and creating temporary triggers that mimic the rollup.

Since Andrew already replied to this discussion, it is most likely that the bug will be fixed before the Summer '19 release on the production servers. Might be worth waiting, depending on your schedule.

Also facing this issue. Will disable the rollups on the case object in sandbox for now and hope the bug gets fixed before summer 19 rollout for production instances.

Thanks for all who replied back to me. On a side note, the managed package requires to enable the remote site and case triggered every time when a new DX package is installed in a sandbox. So moving to an unmanaged package is still tempting for us.

Btw, this code is definitely amazing. Thanks for sharing this in public.

@aparnagkrishna @deckblad @qswh

Andy created a patch version 2.11.1 and I have tested clean installs and upgrades from 2.11 in both Summer '19 and Spring '19 orgs and it seems to resolve this issue in a way that can be used in either Instance. Before it gets added to the readme it would be great for some of you fine folks to help test it out and verify no one is seeing any other issues. Here is the sandbox install link:

test.salesforce.com/packaging/installPackage.apexp?p0=04t0N000001E2L5

@aparnagkrishna @deckblad @qswh / Anyone else: Can all of you confirm that patch 2.11.1 solves the problem in both Summer '19 sandboxes and Spring '19? The first Production Instances go to Summer '19 in only 7 days, so we'd like to get this out there quickly, but with further validation from you.

@JimBTek I have ran some tests in my sandboxes and can confirm the patch solves the issue.

@JimBTek This solved the errors for our full sandbox as well.

@JimBTek Thank you! Resolved errors in my Summer '19 sandbox.

This patch looks to be working on two sandboxes so far.

Yes, it worked for me in Summer '19 sandbox. Was able to edit and create cases again. Thank you!

The actual Salesforce fix for this issue can be tracked here. Meanwhile the above patch will suffice. But if you are concerned about upgrading (the patch is against latest) you may want to track the Salesforce fix instead.

@JimBTek @afawcett is it worth upgrading production orgs to v2.11.1 prior to Summer '19 rolling out? It doesn't seem like anyone has confirmed that it works as expected in Spring '19 sandboxes.

Confirmed that v2.11.1 patch works on both Spring '19 and Summer '19 sandboxes.

I am closing this issue. the 2.11.1 patch has been released and is in the readme to install in prod or sandboxes. It is compatible with Spring '19 and Summer '19

Hello! I'm on 2.12 and have the Deploy code to support record merging? marked TRUE on my trigger, but I'm still receiving an error when editing a case that's been merged. I've removed and re-deployed the trigger a few times, but still receiving the error. I installed 2.12 last week, case merge was turned on after the fact, but I did the re-deployment of the trigger today once discovering the issue. This is in production.. What can I do to fix this?

Hello! I'm on 2.12 and have the Deploy code to support record merging? marked TRUE on my trigger, but I'm still receiving an error when editing a case that's been merged. I've removed and re-deployed the trigger a few times, but still receiving the error. I installed 2.12 last week, case merge was turned on after the fact, but I did the re-deployment of the trigger today once discovering the issue. This is in production.. What can I do to fix this?

did you get this resolved?