sf org permset assign -b does not work with a User Alias

[hackbac]

Summary

sf org permset assign -b does not work with a User Alias

Steps To Reproduce

Query for a User Alias:

~  $ sf data query --query "SELECT Username, Alias FROM User WHERE Username = '[email protected]'" -o [email protected]
Querying Data... ⣽
 USERNAME                      ALIAS
 ───────────────────────────── ─────
 [email protected] UUser
Querying Data... done

Assigning the permission set on behalf of an alias results in an error:

~  $ sf org permset assign -b UUser -n Edit_Account_Enable_External_Account_Hierarchy -o [email protected]
Error (1): No record found for SELECT Id FROM User WHERE Username='UUser'

Assigning the permission set on behalf of a username is successful:

~  $ sf org permset assign -b [email protected] -n Edit_Account_Enable_External_Account_Hierarchy -o [email protected]

 Username                      Permission Set Assignment
 ───────────────────────────── ──────────────────────────────────────────────
 [email protected] Edit_Account_Enable_External_Account_Hierarchy

Expected result

Per the command help, the -b flag should accept an Alias to indicate a User.

~  $ sf org permset assign -h
Assign a permission set to one or more users of a scratch org.

USAGE
  $ sf org assign permset -n <value> -o <value> [--json] [-b <value>] [--api-version <value>]

FLAGS
  -b, --on-behalf-of=<value>...  Username or alias to assign the permission set to.

Actual result

Assigning the permission set on behalf of an alias results in an error:

~  $ sf org permset assign -b UUser -n Edit_Account_Enable_External_Account_Hierarchy -o [email protected]
Error (1): No record found for SELECT Id FROM User WHERE Username='UUser'

System Information

{
  "architecture": "darwin-arm64",
  "cliVersion": "@salesforce/cli/2.15.9",
  "nodeVersion": "node-v18.15.0",
  "osVersion": "Darwin 22.5.0",
  "rootPath": "/Users/bchong/.local/share/sf/client/2.15.9-ffa76de",
  "shell": "zsh",
  "pluginVersions": [
    "@mshanemc/plugin-streaming 1.1.7 (user)",
    "@mshanemc/sfdx-sosl 1.1.0 (user)",
    "@oclif/plugin-autocomplete 2.3.10 (core)",
    "@oclif/plugin-commands 3.0.4 (core)",
    "@oclif/plugin-help 6.0.4 (core)",
    "@oclif/plugin-not-found 3.0.2 (core)",
    "@oclif/plugin-plugins 3.9.4 (core)",
    "@oclif/plugin-search 1.0.4 (core)",
    "@oclif/plugin-update 4.1.3 (core)",
    "@oclif/plugin-version 2.0.3 (core)",
    "@oclif/plugin-warn-if-update-available 3.0.2 (core)",
    "@oclif/plugin-which 3.0.6 (core)",
    "@salesforce/cli 2.15.9 (core)",
    "apex 2.3.20 (core)",
    "auth 2.8.25 (core)",
    "data 2.6.1 (core)",
    "deploy-retrieve 1.19.2 (core)",
    "info 2.6.51 (core)",
    "limits 2.3.41 (core)",
    "login 1.2.39 (core)",
    "marketplace 0.3.1 (core)",
    "org 2.11.5 (core)",
    "schema 2.3.31 (core)",
    "settings 1.4.36 (core)",
    "sobject 0.2.14 (core)",
    "source 2.10.45 (core)",
    "telemetry 2.3.8 (core)",
    "templates 55.5.17 (core)",
    "trust 2.6.22 (core)",
    "user 2.3.39 (core)",
    "shane-sfdx-plugins 4.43.0 (user)"
  ]
}

Additional information

[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.

[shetzel]

This is working as designed.
"Alias" in the CLI context means an alias assigned to that username by the CLI. E.g., sf org create user --set-alias me or sf org create scratch --set-alias testOrg It is completely different from a user alias within a Salesforce org.

[hackbac]

@shetzel thanks for the feedback, although I'm not sure that it makes sense to me.

First, the help text uses different phrases for "alias" in each context ("org alias" vs "Username or alias".)

FLAGS
  -b, --on-behalf-of=<value>...  Username or alias to assign the permission set to.
  -o, --target-org=<value>       (required) Scratch org alias or login user.

Second, since the --target-org value is required, it assumes the org's logged in username when -b is not specified.

  $ sf org list
   Type    Alias                         Username
   Scratch org-alias                     [email protected]
   Scratch org-alias-b                   [email protected]

Note that using the org alias automatically sets the permission set to the username.

 $ sf org permset assign -n Edit_Account_Enable_External_Account_Hierarchy -o org-alias
=== Permsets Assigned

 Username                      Permission Set Assignment
 ───────────────────────────── ──────────────────────────────────────────────
 [email protected] Edit_Account_Enable_External_Account_Hierarchy

And it would not make much sense to provide a different org alias than that of the target org

$  sf org permset assign -n Edit_Account_Enable_External_Account_Hierarchy -o org-alias -b org-alias-b
Error (1): No record found for SELECT Id FROM User WHERE Username='[email protected]'

In my opinion, it makes more sense to be able to automate the assignment of a permission set to a User's Alias across multiple environments since the username changes. Comparing the two examples below, the second one would potentially require querying the username in every sandbox environment:

sf org permset assign -n Perm_Set -o dev -b SalesOpsUser 
sf org permset assign -n Perm_Set -o uat -b SalesOpsUser 
sf org permset assign -n Perm_Set -o prod -b SalesOpsUser 

vs

sf org permset assign -n Perm_Set -o dev -b [email protected] 
sf org permset assign -n Perm_Set -o uat -b [email protected] 
sf org permset assign -n Perm_Set -o prod -b [email protected]

Thanks for the consideration.

[shetzel]

Both flag values are usernames or CLI aliases for usernames. All CLI commands that target Salesforce orgs act as the specified username, which comes from a config variable or explicitly set as a flag on the command. As part of creating a scratch org an admin user is also created and that is what the CLI uses for API requests. So "Scratch org alias" in the command help is referring to an alias that you can specify for the admin user when you create the scratch org.

When assigning permsets, you can assign them to yourself (i.e., as the person executing the command) or you can assign the permset to another user (by username) in the target org. This way, you can create test users from the CLI that may not have permissions to assign permsets to themselves, so an admin user does it for them as part of setup steps. E.g., sf org create user -a testUser1. Then you can sf org permset assign -n MyPermSet -b testUser1.