Unit test failing fflib_SecurityUtilsTest & sysadmin_objectAndField_access about fflib-apex-common HOT 8 CLOSED

G'day @wimvelzeboer -- Am I correct that your exception is occurring during the package version creation sequence and not simply with a deployment to a regular scratch org? Does the sfdx-project.json file list your specific scratch org def file explicitly or are you relying on the default scratch org def file during package version creation?

from fflib-apex-common.

@ImJohnMDaniel Yes, the exception only occurs during the creation of the package version sequence. I do not provide the --definition-file= during package version creation (see also the last line of the script), is that what you mean?

from fflib-apex-common.

You could specify the --definition-file flag or you could simply include it in the package's packageDirectory section of information in the sfdx-project.json file.

Since you are doing neither, the package version create process will ignore your scratch org definition file and use the default one. I am not sure that would help though. All scratch orgs are suppose to have "System Administrator" profiles.

I definitely don't have any other reports of this issue so I would recommend opening a support case with Salesforce and get them to explain why there is a failure there.

from fflib-apex-common.

If you want to get a little further down the rabbit hole, I'd suggest just deploying a single Apex test class with a test method that queries the list of Profiles that are in the build org and emits that list as a test failure -- so that you can see what Profiles are present. To John's point, this doesn't sound like an AEP bug -- it sounds like a 2GP build org anomaly.

Historically, creating a package version with 2GP required you to wrap all tests in System.runAs() to ensure you were running the tests during packaging as a reliably permissioned user. Then, the packaging team introduced the apexTestAccess property in sfdx-project.json so that you could have perm sets auto-assigned to your user:

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_unlocked_pkg_unpackaged_md.htm

But I don't think that's what at play here -- you can't grant CRUD/FLS on Profile so you can't add them to Perm Sets.

from fflib-apex-common.

@daveespo I did what you suggested, and it came up with a list of profiles that did not contain "System Administrator".

It did however contain Järjestelmän pääkäyttäjä, which is Finnish for "System Administrator". The DevOrg that I am using for this unlocked managed package is from a company located in Finland....

Any suggestions on how to solve this issue?

from fflib-apex-common.

Excellent debugging!

Sadly, the DeveloperName of the Profile isn't accessible via SOQL which presents a challenge

Can you try setting country and/or language in your scratch org definition file to get back to an English locale?

https://developer.salesforce.com/docs/atlas.en-us.sfdx_dev.meta/sfdx_dev/sfdx_dev_scratch_orgs_def_file.htm

That won't help with day-to-day scratch org development but should solve your packaging problem

from fflib-apex-common.

@daveespo No you are excellent!!

I added the country and the language to the project-scratch-def.json and added the --definition-file flag to the package creation, and that worked!

project-scratch-def.json

{
  "orgName": "FFLIB Frameworks",
  "edition": "Developer",
  "country": "US",
  "language": "en_US",
  "features": ["EnableSetPasswordInApi"],
  "settings": {
    "lightningExperienceSettings": {
      "enableS1DesktopEnabled": true
    },
    "mobileSettings": {
      "enableS1EncryptedStoragePref2": false
    }
  }
}

Package creation command:

sf package version create --installation-key ${{ vars.INSTALLATION_KEY }} --package ${{ vars.PACKAGE_ID }} --definition-file config/project-scratch-def.json --code-coverage -w 30

Thank you both for your help!

from fflib-apex-common.

Great! Glad to get it sorted quickly!

from fflib-apex-common.