Package Version Creation - all dependencies are installed for AllUsers

[dschach]

Summary

We have a package with dependencies on other packages. We want to create a new PackageVersion.

One of the dependencies has a custom permission (to disable triggers) that we DO NOT want added to every profile in an org.

Creation of a package version "installs" the dependencies in that ephemeral creation system with AllUsers and we know this because version creation fails with errors that only happen if the triggers in our package are disabled.

Steps To Reproduce

We have a repository but it is private for Department of Veterans Affairs. Please contact me for a demo.

1. Create a package that contains a Custom Permission (Package1)
2. Create a second package dependent on the first (Package2).
   • Write a trigger in Package2 that exits if the flag is on the user's profile, and does something if that flag is not present.
   • Write a test that verifies that a trigger that references that bypass flag fires if the user does not have the flag
3. Create a package version of Package2

Expected result

The docs say that packages install with AdminsOnly by default, so it is expected that the package version can be created.

Actual result

Package version creation fails because no trigger tests pass because Package1 put the bypass custom permission on every profile.

System Information

OSX zsh in VSCode

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.51.6",
  "nodeVersion": "node-v20.15.0",
  "osVersion": "Darwin 23.5.0",
  "rootPath": "/Users/dschach/.local/share/sf/client/2.51.6-e49d0be",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.1.7 (core)",
    "@oclif/plugin-commands 4.0.7 (core)",
    "@oclif/plugin-help 6.2.6 (core)",
    "@oclif/plugin-not-found 3.2.11 (core)",
    "@oclif/plugin-plugins 5.3.7 (core)",
    "@oclif/plugin-search 1.2.3 (core)",
    "@oclif/plugin-update 4.4.9 (core)",
    "@oclif/plugin-version 2.2.8 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.9 (core)",
    "@oclif/plugin-which 3.2.8 (core)",
    "@salesforce/cli 2.51.6 (core)",
    "apex 3.2.5 (core)",
    "auth 3.6.36 (core)",
    "data 3.5.5 (core)",
    "deploy-retrieve 3.9.17 (core)",
    "dev 2.3.6 (user) published 5 days ago (Fri Jul 19 2024)",
    "info 3.3.18 (core)",
    "limits 3.3.18 (core)",
    "marketplace 1.2.18 (core)",
    "org 4.3.5 (core)",
    "packaging 2.7.1 (core)",
    "schema 3.3.19 (core)",
    "settings 2.3.8 (core)",
    "sobject 1.4.19 (core)",
    "source 3.5.5 (core)",
    "telemetry 3.6.2 (core)",
    "templates 56.3.3 (core)",
    "trust 3.7.13 (core)",
    "user 3.5.18 (core)",
    "@salesforce/sfdx-scanner 4.3.2 (user) published 21 days ago (Wed Jul 03 2024)"
  ]
}

Additional information

FEATURE REQUEST:

• Flag on each package dependency in sfdx-project.json to specify if that dependency should be installed with AdminsOnly, AllUsers, or (maybe) an array of profile names
• Flag on package version create that forces all dependent packages to be installed in that creation org with a specific security-type

It even fails if I put a profile in unpackagedMetadata, and I don't want to have to package a profile in Package2 if I don't have to.

[github-actions]

Thank you for filing this issue. We appreciate your feedback and will review the issue as soon as possible. Remember, however, that GitHub isn't a mechanism for receiving support under any agreement or SLA. If you require immediate assistance, contact Salesforce Customer Support.

[sethmuss]

Hello @dschach , thanks for the detailed description of what you're facing. Which doc are you referring to vis-a-vis "The docs say that packages install with AdminsOnly by default?" AFAIK the ephemeral build system has only one user so in effect AdminsOnly == AllUsers, but maybe there circumstances where that is not the case, that ephemeral system is complicated and built on scratch orgs so...

Just so I make sure I'm understanding: the reason package2 fails to have a version created is due to a test failure? And if that's the case then the pain is simply having to change the test, or is there further pain points? (I'm not implying changing test code isn't a big deal, just want to make sure I'm fully grokking the problem scope)

I understand your feature requests and can put them in front of our product team. Since this is issue is more of an issue/feature-request hybrid: what would help your case:

1. A link to a conversation on trailhead community (stack overflow, etc) where you've solicited advice from other packaging experts on your situation and haven't been able to solve the problem.
2. A distilled project zip file containing the metadata for package1 and 2. This would aide in reproducing your failure.

Thank you!
Seth

[dschach]

Hi @sethmuss -

The ephemeral build system has multiple users. One of our devs found that the last names are Agent, Signup, BuildOrg, User, User, testBaseProfile, Smith, Amos.

The docs for package version create don't explicitly say AdminsOnly, but package install says that this is the default.

The reason Package2 is failing to create is because a test is failing - a test that would not fail if the dependency were installed AdminsOnly.

It's difficult to make a zip with all the items, but I can see about spinning up something.

In the meantime, the issue stands that ISVs and package creators have no input into how the dependencies are installed in the ephemeral build system, which can lead to undesired outcomes.

[jdschleicher]

I believe this will help reproduce

example packages are attached as zip files and a separate devhub will be needed to create them and complete the troubleshooting steps.

// step 1 - make sure triage_packageOneWithCustomPermission .zip is extracted and opened in dedicated vs directory
sf package create --name TriagePackageOne --description "Triaging Custom Permission Issue" --package-type Unlocked --path force-app --no-namespace --target-dev-hub personal_devhub

// step 2
sf package version create --package TriagePackageOne --installation-key-bypass --wait 10 --target-dev-hub personal_devhub

sf org create scratch --alias package2WithTestClass --edition enterprise --target-dev-hub personal_devhub
sf package install --package 04t_from_step_2 --target-org package2WithTestClass

<!-- The above install only added the custom permission to the system admin profile as expected (install defaults to admins only -- not all users) -->
<!-- In scratch org 2, only created a validation rule that fires if the user does not have a custom permission from the above package and an apex test class that should trigger the validation rule due to the test user not having the custom permission due to their profile being standard user -->

// step 3 - make sure triage_packageTwoWithDependency.zip is extracted and opened in dedicated directory
sf package create --name TriagePackageTwo --description "Triaging profile having dependent package's custom permission" --package-type Unlocked --path force-app --no-namespace --target-dev-hub personal_devhub

// step 4 update package two dependencies in sfdx-project.json with 04t_id from step 2

// step 5
sf package version create --package TriagePackageTwo --installation-key-bypass --wait 10 --target-dev-hub personal_devhub --code-coverage

<!-- Fails when doing package version create for TriagePackageTwo and running code coverage -->

triage_packageTwoWithDependency (1).zip
triage_packageOneWithCustomPermission (1).zip

expected error message:

[github-actions]

We have determined that the issue you reported exists in code owned by another team that uses only the official support channels. To ensure that your issue is addressed, open an official Salesforce customer support ticket with a link to this issue. We encourage anyone experiencing this issue to do the same to increase the priority. We will keep this issue open for the community to collaborate on.