Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

System.SObjectException: Field xxx is not editable #97

Closed
mickster04 opened this issue May 11, 2021 · 3 comments · Fixed by #96
Closed

System.SObjectException: Field xxx is not editable #97

mickster04 opened this issue May 11, 2021 · 3 comments · Fixed by #96

Comments

@mickster04
Copy link

System.SObjectException: Field Score__c is not editable
Class.RollupEvaluator.RecursiveUpdateEvaluator.matches: line 637, column 1
Class.RollupEvaluator.CombinedEvaluator.matches: line 90, column 1

when running a MDT rollup against a lead from custom child object I am presented the above exception. the field in question is of type Formula (Number)

the code
clonedItem.put(this.metadata.RollupFieldOnCalcItem__c, calcItem.get(this.metadata.RollupFieldOnCalcItem__c));
seems to be setting the field to manage recursion tracking?

I don't quite follow but obviously what I would like to know is how do I get this roll up to work? Do i need to replicate the field somehow, or is this not even possible with rollup? or is there some further config I can do

Please ask questions as I don't know what information you might need here. I also had a read through the doco and couldn't see anything that mentioned my situation?

@jamessimone
Copy link
Owner

Hey @mickster04, thanks for reporting this. I will fix this tomorrow morning, also as part of the v1.2.17 release. Apologies that you’re running into this issue; for now you can get this working by commenting out line 49 in RollupEvaluator.cls - thanks for reporting, and apologies for the problem!

@mickster04
Copy link
Author

Awesome! thanks! I did wonder if it was possible to manage recursion with just the ID? anyway, I look forward to your update!

@jamessimone
Copy link
Owner

@mickster04 if only it were as simple as using the Ids - however, the intent with recursion detection is not only to stop running if the items have been run through, but also to check if any of the items have changed prior to doing so. For Rollup's purposes, that means validating that the lookup Id and/or the value to rollup haven't changed. If they have changed, then the recursion is a valid place for rolling up to occur.

jamessimone added a commit that referenced this issue May 11, 2021
)

* Fixes #95 by fixing restrictiveness level for RollupEvaluator

* Tweaks for #88 to fully support automated pipeline

* Further fixes for #95 after getting feedback from Katherine on beta package version

* Fixing README typo

* Updating batch method to properly intake RollupInvocationPoint

* Fix apex issue where not all code paths were setting CalcItem__c on Rollup__mdt synthetic records

* Add baseline logging

* Add more logging areas

* Removing current branch from package:version:create invocation, as that royally borks the format of the package version Id in sfdx-project.json

* Added even better logging for invocables

* First take on addendum for v1.2.17, patching holes in current RollupCalculator functionality for full recalculation routes that weren't already covered (so, everything besides average/first/last)

* Added baseBaseCalculation method in RollupCalculator to deal with the possibility of rollups where the evaluator filters out all calc items necessitating a full recalc - which would not have happened for String and Number-based rollups previously

* Fixes #97 by properly handling unwriteable fields in recursive check

* added safe guards when migrating from DLRS (#98)

* Pretty-ing up  contribution to scripts/convert-dlrs-rules.apex
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants