Inherited Sharing not respected in trigger context

Question

I know the differences between declaring a class inherited sharing, or leave it omitted, and between it and with sharing or without sharing, however I decided to test all the theory in the documentation in a real scenario.

-I have a trigger on account (API VERSION 45), it calls Account handler(API VERSION 45), which is with sharing.

-Account handler calls AccountUtil (API VERSION 48):

-AccountHandler relevant code:

public with sharing class AccountHandler implements ITrigger
{
    public void beforeInsert(list<SObject> newList)
    {
        AccountUtil.queryAccounts();
    }

-AccountUtil relevant code:

public inherited sharing class AccountUtil
{
    public static void queryAccounts()
    {
        //When called from trigger, no sharing specified = without sharing, and inherited sharing specified = without sharing too (WHY IS THIS IF IT IS CALLED FROM AccountHandler WHICH IS with sharing?)
        //When called as custom controller or controller extension for a vf page, no sharing specified = without sharing, and inherited sharing specified = with sharing

        //With sharing is respected, from a trigger, even if security is not enforced in anyway in any other place in the class
        for (Account acc : [SELECT Id, Name, SLASerialNumber__c FROM Account]) {
            System.debug('acc: ' + acc);
            if (String.isNotBlank(acc.SLASerialNumber__c)) {
                acc1 = acc;
                acc1Serial = acc.SLASerialNumber__c;
            }
        }

I have written down my conclusions as comments, however, my question is, why it runs as without sharing when it has inherited sharing (either specified or omitted) if it is called from AccountHandler, which is with sharing?

UPDATE:

I wanted to Test the possibility of AccountUtil being inheriting the sharing from the top level class, instead of doing it from the class that direcly called it.

To do that:

-I put AccountHandler (WITH SHARING) as a custom controller for a VF page, that calls Intermediary.cls

-I created Intermediary.cls class (WITHOUT SHARING, API VERSION 48) that calls AccountUtil

-AccountUtil, with inherited sharing, either splicitly declared or omitted, runs without sharing, following previous immediate previous class sharing. If Intermediary.cls is changed to be WITH SHARING, AccountUtil will runs under WITH SHARING too.

Basically:

-Class a with sharing is custom controller and call class b

-Class b is without sharing and call class c

-Class c has inherithed sharing, either declared explicitly or omitted, and runs as without sharing

-If b is changed to with sharing, then c runs as with sharing too

So class c does not actually follow class a top level class sharing, but b, where is it called from.

Update:

I just checked that, if a user is using a with sharing class and trying to update a record that he does not have record level access to, it will run in a insufficient access record, while this will not happen if the class is without sharing.

Answer 1

I tried to do the same test and it worked for me. This is what I created:

// Trigger

trigger AccountTrigger on Account (before insert) {
    System.debug(AccountHandler.callAccountUtil());
}

// Account Handler

public with sharing class AccountHandler {
    public static List<Account> callAccountUtil() {
        return AccountUtil.queryAccounts();
    }
}

// Account Util

public inherited sharing class AccountUtil {
    public static List<Account> queryAccounts() {
        return [SELECT Name FROM Account];
    }
}

The test I did was: I set Account org wide defaults to private, then I created a user which has a Standard User profile, and I created one account with that user. I checked that only that account was visible for him. Then, I setup the debug logs with the sys admin and I created a second account with the standard user. The debug log correctly shows just the first created account (and not the others in the org, created by other users).

First, I did the test with all my classes on api 48.0. Then I changed the trigger and the AccountHandler class to API 45.0, and it worked the same.

So, maybe it's an issue with your with your test scenario setup? We can drop on a call and see what we have different, if you want.

Answer 2

Triggers run in "system mode", where user permissions and sharing are not applied.

By delegating to Apex "with sharing" you can get the current user's sharing to be applied.

I am guessing that, because triggers are a bit "special", there may be some different handling of undeclared (and perhaps explicitly declared) inherited sharing, even when invoked indirectly. I don't know if it is a bug or simply undocumented behaviour.

There is some possibly a little out-of-date detail in this other thread that may be of interest.