Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

salesforce/core vs jsforce Connection customPermissions difference #3156

Closed
Kevmo92 opened this issue Dec 17, 2024 · 3 comments
Closed

salesforce/core vs jsforce Connection customPermissions difference #3156

Kevmo92 opened this issue Dec 17, 2024 · 3 comments
Labels
investigating We're actively investigating this issue validated Version information for this issue has been validated

Comments

@Kevmo92
Copy link

Kevmo92 commented Dec 17, 2024

Summary

When using the jsforce connection to install a package via a tooling sobject PackageInstallRequest create command and then running an apex test in the scratch org to determine assigned custom permissions to a user that is created in the apex test customPermissions are automatically being assigned.

Versus using the salesforce/core connection to install the same package and running the same unit test no customPermissions are being automatically assigned to the user created in the test.

I'd like to understand the difference between using the two different connections and why a jsforce connection is assigning custom Permissions to users created in apex tests.

Steps To Reproduce

I've created a public repo that uses a ci build to showcase the difference between the two connections (jsforce and salesforce/core).

To see the differences either:

  1. Open a pull request and uncomment the commented out code in the .github/workflows/demo-ci.yml file and comment out the 📲 Install Package Version to Scratch org 📭 named step. Watch the ci build and notice the one unit test fails. Reverse the commenting of code and watch the ci build run. Notice the one unit test now passes.
  2. View the previous action runs in the repo.

Expected result

After installing a package into a scratch org using the jsforce connection I would expect the same behavior when running apex tests in the org if i had installed the package with the salesforce/core connection.

Actual result

Additional customPermissions are being assigned to a user created in an apex test when using the jsforce connection.

Additional information

I believe when using the sf package install command it is using the salesforce/core connection to run the install. What is confusing to me is that the salesforce/core connection extends the jsforce connection class 🤔

Connection classes in question:
https://github.com/jsforce/jsforce/blob/main/src/connection.ts

https://github.com/forcedotcom/sfdx-core/blob/main/src/org/connection.ts

How both scripts are calling the PackageInstallRequst

const response = await conn.tooling.sobject('PackageInstallRequest').create({
      SubscriberPackageVersionKey: packageId,
      NameConflictResolution: 'Block',
      SecurityType: 'None',
      ApexCompileType: 'package',
      SkipHandlers: 'FeatureEnforcement',
    });

Related api docs https://developer.salesforce.com/docs/atlas.en-us.api_tooling.meta/api_tooling/tooling_api_objects_packageinstallrequest.htm

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.69.14",
  "nodeVersion": "node-v22.12.0",
  "osVersion": "Darwin 23.6.0",
  "rootPath": "/Users/kevin.watson/.local/share/fnm/node-versions/v22.12.0/installation/lib/node_modules/@salesforce/cli",
  "shell": "zsh",
  "pluginVersions": [
    "@oclif/plugin-autocomplete 3.2.11 (core)",
    "@oclif/plugin-commands 4.1.12 (core)",
    "@oclif/plugin-help 6.2.18 (core)",
    "@oclif/plugin-not-found 3.2.29 (core)",
    "@oclif/plugin-plugins 5.4.19 (core)",
    "@oclif/plugin-search 1.2.16 (core)",
    "@oclif/plugin-update 4.6.14 (core)",
    "@oclif/plugin-version 2.2.16 (core)",
    "@oclif/plugin-warn-if-update-available 3.1.24 (core)",
    "@oclif/plugin-which 3.2.19 (core)",
    "@salesforce/cli 2.69.14 (core)",
    "apex 3.6.6 (core)",
    "api 1.3.2 (core)",
    "auth 3.6.78 (core)",
    "data 3.12.3 (core)",
    "deploy-retrieve 3.15.17 (core)",
    "info 3.4.25 (core)",
    "limits 3.3.42 (core)",
    "marketplace 1.3.7 (core)",
    "org 5.2.7 (core)",
    "packaging 2.9.5 (core)",
    "schema 3.3.43 (core)",
    "settings 2.4.8 (core)",
    "sobject 1.4.46 (core)",
    "telemetry 3.6.26 (core)",
    "templates 56.3.33 (core)",
    "trust 3.7.45 (core)",
    "user 3.6.4 (core)"
  ]
}
@Kevmo92 Kevmo92 added the investigating We're actively investigating this issue label Dec 17, 2024
Copy link

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.

@github-actions github-actions bot added the validated Version information for this issue has been validated label Dec 17, 2024
@Kevmo92 Kevmo92 changed the title salesforce/core vs jsforce Connection permission difference salesforce/core vs jsforce Connection customPermissions difference Dec 18, 2024
@Kevmo92
Copy link
Author

Kevmo92 commented Dec 18, 2024

Digging into this more, I've narrowed this down to the jsforce connection adding the custom Permission to the Standard User profile. This shouldn't be happening since I'm using the SecurityType: None for both the jsforce and salesforce/core connection calls.

Screenshots of two different scratch orgs after installing the package:

jsForceInstall
sfCoreInstall

@Kevmo92
Copy link
Author

Kevmo92 commented Dec 18, 2024

Going to open an issue in jsforce's repo!

@Kevmo92 Kevmo92 closed this as completed Dec 18, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
investigating We're actively investigating this issue validated Version information for this issue has been validated
Projects
None yet
Development

No branches or pull requests

1 participant