2

In line with current security standards, we use with security_enforced extensively in our code. When doing CI (Continuous Integration) builds or working interactively we use sfdx force:user:permset:assign to assign permission sets that grant the field level access so the Apex tests pass. And when our product is installed no tests are run so no problem there.

But packaging 2 creates the packaging org on the fly and runs the Apex tests with no hook point to do any org preparation. So what strategy works to get the right field level permissions set?

  • Duplicate all the permissions in the Admin.profile-meta.xml?
    • This assumes that the packaging process does use that profile. Does it?
    • And that the Admin.profile-meta.xml is applied in the packaging org. Is it?
  • Assign the permission sets programatically in the @TestSetup method of every test? But that then has MIXED_DML_OPERATION challenges.
  • Modify the product code to not do security checks when tests are running. (Yuk.)
  • Better approaches?

We are getting test failures on packaging related to custom fields we add to the Event object and are trying to figure out why.

5
  • 1
    I must say, we do cheat and turn off checks in test executions. We do this via use of our own class that delegates to the standard schema checks. This as a major downside that Checkmarx flags everything as not applying CRUD/FLS checks because it does shallow code path analysis.
    – Phil W
    Aug 24, 2021 at 11:24
  • Yeah Phil, sometimes the pragmatic approach is necessary when the options narrow down too much in Salesforce.
    – Keith C
    Aug 24, 2021 at 11:36
  • @PhilW You don't need to "cheat" anymore, there's an official path you can take to avoid this problem of yours.
    – sfdcfox
    Aug 24, 2021 at 12:32
  • 2
    Yes, good for 2GP. Our cheating originates in 1GP. We should break the habit though ;)
    – Phil W
    Aug 24, 2021 at 12:39
  • 2
    @PhilW Yeah, we ourselves are stuck on 1GMP until they provide a solid 2GMP migration path. Supposedly might be available in 2022 or so. Our package needed this like last year.
    – sfdcfox
    Aug 24, 2021 at 13:06

1 Answer 1

7

You can specify permission sets to use for version creation. A snippet is provided in the documentation.

"packageDirectories": [
    {
        "path": "force-app",
        "package": "TV_unl", 
        "versionName": "ver 0.1",
        "versionNumber": "0.1.0.NEXT",
        "default": true, 
        "unpackagedMetadata": {
            "path": "my-unpackaged-directory"
        },
        "apexTestAccess": {
               "permissionSets": [
                   "Permission_Set_1",
                   "Permission_Set_2"
               ],
               "permissionSetLicenses": [
                   "SalesConsoleUser"
               ]
           }

    }, 
    {
        "path": "my-unpackaged-directory",
        "default": false
    }
]

This means that you won't need to write permissions into your tests, you won't need to intentionally dumb down security and risk false security flags in Checkmarx, and you'll eliminate most of your challenges when building new versions of your packages.

1
  • Wow that is exactly what I need. Glad someone reads the docs...
    – Keith C
    Aug 24, 2021 at 13:40

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .