Expected a QueryException due to read only user not having access to Opportunity

[matthewpomar-at-reddit]

Describe the bug Getting the following error while running test:

System.AssertException: Assertion Failed: Assertion failed: Expected a QueryException due to read only user not having access to Opportunity Class.fflib_SObjectSelectorTest.toSOQL_When_UserModeAndUserCannnotReadObject_Expect_QueryException: line 384, column 1

To Reproduce

1. Update to the latest version of Apex Common
2. Verify (or set) Read permissions on Opportunity on "Read Only" security profile
3. Run fflib_SObjectSelectorTest.toSOQL_When_UserModeAndUserCannnotReadObject_Expect_QueryException

Expected behavior I would expect the test to pass. Here's where the code should be throwing the QueryException:

sel.selectSObjectsById(new Set<Id>{fflib_IDGenerator.generate(Opportunity.SObjectType)});

It's worth noting that if I remove Read only access to the Opportunity object on the Read Only security profile, the error is thrown and the test passes. However, we don't want to remove read access to this object. Not sure if this is intended to be setup this way for the test to pass or not.

Screenshots and text of error observed

15:50:49.864 (1933998943)|FATAL_ERROR|System.AssertException: Assertion Failed: Assertion failed: Expected a QueryException due to read only user not having access to Opportunity Class.fflib_SObjectSelectorTest.toSOQL_When_UserModeAndUserCannnotReadObject_Expect_QueryException: line 384, column 1

Version Latest, including PR 438 (manually patched as I'm also affected by multi-currency bug).

[ImJohnMDaniel]

@matthewpomar-at-reddit -- thanks for sending this over.

Can I get you to reverify the steps to reproduce this issue. I have the codebase, including the changes from PR438 in a scratch org. When I run fflib_SObjectSelectorTest.toSOQL_When_UserModeAndUserCannnotReadObject_Expect_QueryException, the test passes.

[matthewpomar-at-reddit]

@ImJohnMDaniel I have confirmed the test fails when the "Read Only" profile has Read (or more) access to the Opportunity object. If I remove all access from the Opportunity object for that profile, the test passes. Can you confirm this behavior is reflected in your scratch org?

I added a new Step 2 under Reproduction Steps (verify Read access to Opportunity) on my original post.

Thank you for your help.

[matthewpomar-at-reddit]

It seems there is no bug or defect here. However, the library does require that the orgs Read Only security profile be setup in a certain way for the library tests to pass. We had to remove access to the Opportunity object for the Read Only profile in order to get the tests to pass for deployment. Because we cannot leave it this way, I ultimately commented out that part of the test to keep the test passing once we added read only access back to the Opportunity.

[foxysolutions]

This morning I requested a new Developer Edition org, which also resulted in an org where the Read profile. The only thing performed in this org is the installation of fflib-apex-mocks and fflib-apex-common.

It might be worth to check if the access verification can be moved to a less used object like ApexClass for the sake of success. Would this be an ok approach?

[itsmebasti]

I support foxysolutions suggestion, I ran into the same while deploying to a customer's org where I am not supposed to change any permissions.

[wimvelzeboer]

This morning I requested a new Developer Edition org, which also resulted in an org where the Read profile. The only thing performed in this org is the installation of fflib-apex-mocks and fflib-apex-common.

It might be worth to check if the access verification can be moved to a less used object like ApexClass for the sake of success. Would this be an ok approach?

I had the same issue, with a brand new Developer org (no changed made) and fresh checkout of fflib repos. It worked fine when I deployed the same source to a ScratchOrg.

Is anyone already working on a fix?

[michaeljdavisjr]

I also ran into an issue with this. Any updates would be greatly appreciated.