Perms errors caused by "with sharing"?

[sd5000]

Hey, this seems like a great package, thanks for sharing it.

It did break some things due to permissions issues when we created realtime triggers, especially for users who couldn't be added to the "process rollups" permset, such as newly-provisioned portal/communities users and site guest users.

Short term we fixed the problem by granting perms to the custom "metadata" objects in the relevant profiles. But long term that seems a bit awkward. Every time a rollup is added to an object, any user of any type (staff, portal, site guest user) who ever needs to create/update the relevant child object will also need to have perms on the Lookup Summaries configuration object or it will basically break their access to that object. Concerned that will become hard to maintain as more of these triggers are added.

Is it possible the classes used by the trigger are defined as "with sharing" but may not need to be? As I understand, triggers generally run in system mode, and should have permission to query any object, unless they are explicitly defined as "with sharing". If left undeclared would they adapt appropriately?

Related thread (re different package) here from @mscholtz

Thanks again for your work on this.

[afawcett]

Your very welcome thanks for the kind words! 👍

Regarding with sharing, yes probably, though the default is better to honour security, what i could do is add a checkbox to the rollup to get it to ignore it? This would be a good option for backwards compatibility as well. Would that work for you?

BTW, regarding your portal/community users, i can you raise another GithHub issue for this and i'll mark it as an enhancement to provide permission sets that are not bound to a salesforce license, which will resolve this issue. In the meantime you can create your own custom permission sets in your org and assign those instread of adjusting profiles, this might help in the meantime.

[sd5000]

Hard to envision how a checkbox would work. Isn't a class either "with sharing" or "without sharing" (or undeclared)? I wasn't aware that could be changed at runtime.

Since the query that's causing trouble in this case is the query for the Lookup Rollup Summary custom object, would it work to just isolate those "metadata" queries in a separate without-sharing class? Or not declare sharing on that class, which I think would make it run as without-sharing in trigger context. That way sharing on all other objects could be retained, but the trigger would always be able to read the metadata object to figure out what to do.

[afawcett]

Oh i see, its not the parent and child objects the rollups are referencing you want to control 'without sharing' on, its the ability to read the rollup 'metadata' objects without having to have permission to do them, is that what your getting at?

[sd5000]

Yes, exactly. The error we were getting was about the metadata objects:

execution of AfterInsert caused by: dlrs.SObjectDomain.DomainException: Permission to access an dlrs__LookupRollupSummary__c dennied. (dlrs)

[afawcett]

I see, yes i agree users just editing child records should not need access to this object. I've raised this issue to address this. In meantime you have to continue to grant read access to the rollup objects.