sf-plugin-permission-sets 0.4.0 → 0.6.0

package/README.md

@@ -1,6 +1,6 @@
 # sf-plugin-permission-sets
 
-[![NPM](https://img.shields.io/npm/v/sf-plugin-permission-sets.svg?label=sf-plugin-permission-sets)](https://www.npmjs.com/package/sf-plugin-permission-sets) [![Downloads/week](https://img.shields.io/npm/dw/sf-plugin-permission-sets.svg)](https://npmjs.org/package/sf-plugin-permission-sets) [![Stability: experimental](https://img.shields.io/badge/stability-experimental-orange.svg)](https://semver.org/#spec-item-4) [![License](https://img.shields.io/badge/License-BSD%203--Clause-brightgreen.svg)](https://raw.githubusercontent.com/zaclummys/sf-plugin-permission-sets/main/LICENSE.txt)
+[![NPM](https://img.shields.io/npm/v/sf-plugin-permission-sets.svg?label=sf-plugin-permission-sets)](https://www.npmjs.com/package/sf-plugin-permission-sets) [![Downloads/week](https://img.shields.io/npm/dw/sf-plugin-permission-sets.svg)](https://npmjs.org/package/sf-plugin-permission-sets) [![Stability: experimental](https://img.shields.io/badge/stability-experimental-orange.svg)](https://semver.org/#spec-item-4) [![License](https://img.shields.io/badge/License-BSD%203--Clause-brightgreen.svg)](https://raw.githubusercontent.com/zaclummys/sf-plugin-permission-sets/main/LICENSE.md)
 
 > Declarative, GitOps-style management of **permission set assignments** for Salesforce orgs.
 > Define who gets what in version-controlled YAML. The plugin reconciles your org to match it: `plan` then `apply`, just like Terraform.
@@ -15,6 +15,7 @@ Stop clicking through Setup to grant access. Commit a YAML file, open a PR, let
 
 - [Why](#why)
 - [Install](#install)
+- [Org permissions](#org-permissions)
 - [Quick start](#quick-start)
 - [Permission files](#permission-files)
 - [Organizing files](#organizing-files)
@@ -22,9 +23,10 @@ Stop clicking through Setup to grant access. Commit a YAML file, open a PR, let
 - [Validations](#validations)
 - [Commands](#commands)
 - [GitHub Actions](#github-actions)
-- [Inspiration & equivalents](#inspiration--equivalents)
 - [Versioning](#versioning)
 - [Architecture](#architecture)
+- [Development](#development)
+- [License](#license)
 
 ---
 
@@ -54,28 +56,47 @@ Or pin a version:
 sf plugins install sf-plugin-permission-sets@x.y.z
 ```
 
-Requires Salesforce CLI (`sf`) and Node.js 20+.
+Requires Salesforce CLI (`sf`) and Node.js 22.13+.
+
+## Org permissions
+
+What the user behind `--target-org` needs:
+
+| Command | API Enabled | View Setup and Configuration | View Roles and Role Hierarchy | Assign Permission Sets |
+| --- | :---: | :---: | :---: | :---: |
+| `sf ps check` | - | - | - | - |
+| `sf ps validate` | ✓ | ✓ | ✓ | - |
+| `sf ps plan` | ✓ | ✓ | ✓ | - |
+| `sf ps export` | ✓ | ✓ | ✓ | - |
+| `sf ps apply` | ✓ | ✓ | ✓ | ✓ |
+
+✓ Required, - Not required. `Manage Users` is not required, not even for permission set licenses.
+
+Two permission sets, so a pull request job cannot change the org:
+
+- [PS_Plugin_Read](setup/permissionsets/PS_Plugin_Read.permissionset-meta.xml): reads permission set assignments.
+- [PS_Plugin_Write](setup/permissionsets/PS_Plugin_Write.permissionset-meta.xml): reads and modifies permission set assignments.
 
 ## Quick start
 
 ```bash
 # 1. Bootstrap YAML from an existing org (so you don't start from scratch)
-sf ps export --target-org dev --output-file permissions.yml
+sf ps export --target-org dev --output-file permissions/dev.yml
 
 # 2. Edit the files, commit, open a PR. Check them, no org needed:
-sf ps check --file "./permissions/*.yml"
+sf ps check --file "permissions/*.yml"
 
 # 3. Validate against a real org (do the users/permission sets exist?)
-sf ps validate --file "./permissions/*.yml" --target-org dev
+sf ps validate --file "permissions/*.yml" --target-org dev
 
 # 4. See what would change
-sf ps plan --file "./permissions/*.yml" --target-org dev
+sf ps plan --file "permissions/*.yml" --target-org dev
 
 # 5. Apply it (additive by default, only adds)
-sf ps apply --file "./permissions/*.yml" --target-org dev
+sf ps apply --file "permissions/*.yml" --target-org dev
 
 # 6. Full reconcile, including removals (opt-in)
-sf ps apply --file "./permissions/*.yml" --target-org prod --mode sync
+sf ps apply --file "permissions/*.yml" --target-org prod --mode sync
 ```
 
 ## Permission files
@@ -115,6 +136,12 @@ users:
       - Sales_Manager
 ```
 
+### Names are matched case-insensitively
+
+Salesforce compares usernames and API names without regard to case, and so does this plugin. `JDoe@acme.com` and `jdoe@acme.com` are the same user, `Sales_Manager` and `sales_manager` are the same permission set, and every comparison the plugin makes (merging files, de-duplicating, diffing against the org, filtering an export) follows that rule. The spelling you write is the spelling that gets displayed and written back, so a file is never rewritten just to normalize case.
+
+The practical consequence is that declaring the same user twice under different spellings merges the two blocks rather than creating two users, and listing a target twice under different spellings is the same duplicate `check` already warns about.
+
 ### Timed access (expiration)
 
 A permission set or permission set group entry can be a plain name or an object with an `expiration`. The expiration is an ISO 8601 datetime, and Salesforce removes access automatically when it passes. Plain names never expire.
@@ -197,7 +224,8 @@ Every run checks the files first. `check` runs the file checks with no org, and
 | Situation | Checked by | Severity | Result |
 | --- | --- | :---: | --- |
 | Same user in two files with different targets | `check` | ✅ ok | Merged into one model, the point of slicing |
-| Same target listed twice for a user | `check` | ⚠️ warning | Deduped |
+| Same user under two spellings that differ only in case | `check` | ✅ ok | Merged into one user, matching how the org compares usernames |
+| Same target listed twice for a user (case-insensitively) | `check` | ⚠️ warning | Deduped |
 | A user with no scopes, or an empty list | `check` | ⚠️ warning | Ignored as a no-op |
 | Same username key appears twice in one file | `check` | ❌ error | Rejected, the intent is ambiguous |
 | Declared user, permission set, group, or license missing or not unique | `validate` | ❌ error | Run fails before any change |
@@ -209,8 +237,8 @@ Every run checks the files first. `check` runs the file checks with no org, and
 | `sf ps check`    | Static analysis of the files alone: schema, duplicates, conflicts, identifier shape. No org, no auth. |
 | `sf ps validate` | Everything `check` does, plus resolving every user/permission set against the org. |
 | `sf ps plan`     | Compute and display the change set: a read-only preview of what `apply` would do. |
-| `sf ps apply`    | Reconcile the org. Honors `--mode`, prompts before deletes, enforces guardrails. |
 | `sf ps export`   | Generate YAML from the current org state to bootstrap adoption.        |
+| `sf ps apply`    | Reconcile the org. Honors `--mode`, prompts before deletes, enforces guardrails. |
 
 ### `sf ps check`
 
@@ -250,19 +278,15 @@ group, and license referenced actually exists and resolves uniquely.
 
 ```
 USAGE
-  $ sf ps plan -o <org> -f <glob>... [--mode <value>] [--show-unchanged]
-               [--out <file>] [--json]
+  $ sf ps plan -o <org> -f <glob>... [--mode <value>] [--show-unchanged] [--json]
 
 FLAGS
   -o, --target-org=<org>   (required)
   -f, --file=<glob>...     (required) YAML file(s) to read. Repeatable, globs expanded by the plugin.
   --mode=<value>           additive | destructive | sync   [default: additive]
   --show-unchanged         List assignments that already match, instead of only counting them.
-  --out=<file>             Write the computed change set to a plan file that `apply` can run verbatim.
 ```
 
-With `--out` the plan is also saved to a file: the resolved change set (adds, updates, removes with their record ids), the mode it was computed for, and the org it targets. Feed that file to `apply --plan` to execute exactly what you reviewed, with no recomputation. See [Saved plans](#saved-plans).
-
 The body shows only what the mode will do, and unchanged assignments are summarized as a count (pass `--show-unchanged` to list them). The default `additive` run previews only what it grants, and reports the undeclared assignment it won't remove as drift:
 
 ```text
@@ -307,46 +331,6 @@ Unchanged: 4 assignments (--show-unchanged to list).
 Next: sf ps apply -o prod -f "permissions/*.yml" --mode sync
 ```
 
-### `sf ps apply`
-
-```
-USAGE
-  $ sf ps apply -o <org> (-f <glob>... | --plan <file>) [--mode <value>]
-                [--max-deletes <n>] [--dry-run] [--show-unchanged] [--no-prompt] [--json]
-
-FLAGS
-  -o, --target-org=<org>   (required)
-  -f, --file=<glob>...     YAML file(s) to read. Repeatable, globs expanded by the plugin.
-  --plan=<file>            Apply a saved plan file from `plan --out` instead of re-reading YAML.
-  --mode=<value>           additive | destructive | sync   [default: additive]
-  --max-deletes=<n>        Abort if a run would remove more than n assignments. [default: 50]
-  --dry-run                Resolve and diff, print what would happen, change nothing.
-  --show-unchanged         List assignments that already match, instead of only counting them.
-  --no-prompt              Skip the deletion confirmation prompt (for CI).
-```
-
-Provide exactly one source: `--file` (read and diff the YAML now) or `--plan` (run a saved plan). They cannot be combined, and `--mode` cannot accompany `--plan` (the plan already carries its mode). `--max-deletes`, `--dry-run`, and `--no-prompt` apply to both.
-
-Deletions always prompt for confirmation unless `--no-prompt` is set, and are hard-capped by `--max-deletes` so a bad merge can't unassign your whole org. DML is executed with the sObject Collections API and reports partial successes/failures per record.
-
-#### Saved plans
-
-`plan --out` and `apply --plan` split review from execution, so what you approve is exactly what runs:
-
-```bash
-sf ps plan  -o prod -f "permissions/*.yml" --mode sync --out prod.plan
-# ... review prod.plan, get sign-off ...
-sf ps apply -o prod --plan prod.plan
-```
-
-Without a saved plan, `apply` recomputes from the files: it re-reads the YAML, re-resolves every reference to an org id, and re-diffs against live state. Anything that changed since you ran `plan` (an edited file, a renamed permission set, another admin's assignment) silently changes what `apply` does. A saved plan freezes the resolved change set, so `apply --plan` executes those exact records with no recomputation.
-
-Guardrails:
-
-- `apply --plan` refuses a plan built for a different org (the plan records the org id).
-- It refuses a plan file it cannot parse or whose format version it does not recognize.
-- The plan is executed as recorded. If the org drifted after the plan was written, individual records may fail (a removed target, an already-deleted assignment); those surface as per-record failures in the outcome report rather than aborting the run. Re-run `plan` to get a fresh plan when in doubt.
-
 ### `sf ps export`
 
 Read-only. Snapshots the org's current assignments as YAML you can commit and then feed back into the other commands. Writes to a file with `--output-file`, or to stdout when that flag is omitted.
@@ -359,7 +343,7 @@ USAGE
 FLAGS
   -o, --target-org=<org>   (required) Org to read assignments from.
   -f, --output-file=<file> Path of the YAML file to write. Parent directories are created; an existing file is overwritten. Omit to write to stdout.
-  --user=<username>...      Only export these users. Repeatable, matched on exact username.
+  --user=<username>...      Only export these users. Repeatable, matched case-insensitively.
   --kind=<scope>...         Only export these scopes: permissionSets | permissionSetGroups | permissionSetLicenses. Repeatable.
 ```
 
@@ -375,7 +359,7 @@ sf ps export -o prod | diff - permissions/prod.yml
 sf ps export -o prod --user jdoe@acme.com > jdoe.yml
 ```
 
-By default the whole org is exported. `--user` and `--kind` narrow the snapshot: pass either to scope it down, and pass both to intersect (the named users, restricted to the named scopes). Values within a flag are a union, so `--user jdoe@acme.com --user asmith@acme.com` exports both. The `--kind` values are the same scope keys the file uses, so `--kind permissionSetLicenses` reads back exactly the `permissionSetLicenses:` block.
+By default the whole org is exported. `--user` and `--kind` narrow the snapshot: pass either to scope it down, and pass both to intersect (the named users, restricted to the named scopes). Values within a flag are a union, so `--user jdoe@acme.com --user asmith@acme.com` exports both. A `--user` value is matched case-insensitively, so only a user the org really does not hold assignments for is reported as unmatched. The `--kind` values are the same scope keys the file uses, so `--kind permissionSetLicenses` reads back exactly the `permissionSetLicenses:` block.
 
 ```bash
 # Snapshot one team's permission sets and groups only
@@ -386,9 +370,35 @@ sf ps export -o prod --output-file team.yml \
 
 A requested `--user` that has no matching assignments (a typo, or a user who genuinely holds nothing in scope) is reported as a warning and the export continues with whoever matched, so a mistyped username never masquerades as a clean empty file.
 
+### `sf ps apply`
+
+```
+USAGE
+  $ sf ps apply -o <org> -f <glob>... [--mode <value>]
+                [--max-deletes <n>] [--dry-run] [--show-unchanged] [--no-prompt] [--json]
+
+FLAGS
+  -o, --target-org=<org>   (required)
+  -f, --file=<glob>...     (required) YAML file(s) to read. Repeatable, globs expanded by the plugin.
+  --mode=<value>           additive | destructive | sync   [default: additive]
+  --max-deletes=<n>        Abort if a run would remove more than n assignments. [default: 50]
+  --dry-run                Resolve and diff, print what would happen, change nothing.
+  --show-unchanged         List assignments that already match, instead of only counting them.
+  --no-prompt              Skip the deletion confirmation prompt (for CI).
+```
+
+`apply` recomputes from the files every run: it re-reads the YAML, re-resolves every reference to an org id, and re-diffs against live state, then acts per `--mode`. Run `plan` shortly before `apply` so the preview you review reflects what `apply` will do (an edited file, a renamed permission set, or another admin's change between the two shifts the outcome).
+
+> [!CAUTION]
+> `--mode sync` and `--mode destructive` revoke access. Deletions always prompt for confirmation unless `--no-prompt` is set, and are hard-capped by `--max-deletes` so a bad merge can't unassign your whole org.
+
+DML is executed with the sObject Collections API and reports partial successes/failures per record.
+
 ## GitHub Actions
 
-Two dead-simple workflows: check pull requests to main with no org, then apply on merge.
+Three small workflows that build on each other: check pull requests with no org at all, validate the same files against the real org, then apply on merge.
+
+Point the pull request workflows at a `PS_Plugin_Read` user and only the merge workflow at `PS_Plugin_Write` (see [Org permissions](#org-permissions)).
 
 **1. Check pull requests to main** (no org, no secrets):
 
@@ -407,7 +417,7 @@ jobs:
       - uses: actions/checkout@v7
       - uses: actions/setup-node@v7
         with:
-          node-version: 20
+          node-version: 22
 
       - name: Install Salesforce CLI
         run: npm install --global @salesforce/cli
@@ -419,7 +429,41 @@ jobs:
         run: sf ps check --file "permissions/*.yml"
 ```
 
-**2. Apply on merge to main** (needs org auth):
+**2. Validate pull requests against the org** (needs org auth):
+
+```yaml
+# .github/workflows/permissions-validate.yml
+name: permissions-validate
+
+on:
+  pull_request:
+    branches: [main]
+    paths:
+      - "permissions/**"
+
+jobs:
+  validate:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 22
+
+      - name: Install Salesforce CLI
+        run: npm install --global @salesforce/cli
+
+      - name: Install the plugin
+        run: sf plugins install sf-plugin-permission-sets
+
+      - name: Log in to the org
+        run: echo '${{ secrets.SFDX_AUTH_URL }}' | sf org login sfdx-url --sfdx-url-stdin --alias prod
+
+      - name: Validate the permission files
+        run: sf ps validate --file "permissions/*.yml" --target-org prod
+```
+
+**3. Apply on merge to main** (needs org auth):
 
 ```yaml
 # .github/workflows/permissions-apply.yml
@@ -436,7 +480,7 @@ jobs:
       - uses: actions/checkout@v7
       - uses: actions/setup-node@v7
         with:
-          node-version: 20
+          node-version: 22
 
       - name: Install Salesforce CLI
         run: npm install --global @salesforce/cli
@@ -451,18 +495,9 @@ jobs:
         run: sf ps apply --file "permissions/*.yml" --target-org prod --mode sync --no-prompt
 ```
 
-Get the auth URL once with `sf org display --verbose --target-org prod`, copy the `Sfdx Auth Url` value, and save it as a repository secret named `SFDX_AUTH_URL`.
-
-Want the diff on the PR before merging? Add a `sf ps plan --file "permissions/*.yml" --target-org prod` step (it needs the same org auth) to the check workflow.
-
-## Inspiration & equivalents
-
-This plugin's command surface borrows ideas from tools you already know:
+Workflows 2 and 3 share one secret. Get the auth URL once with `sf org display --verbose --target-org prod`, copy the `Sfdx Auth Url` value, and save it as a repository secret named `SFDX_AUTH_URL`.
 
-- [Terraform](https://developer.hashicorp.com/terraform/docs)
-- [AWS CLI](https://docs.aws.amazon.com/cli/latest/userguide/)
-- [AWS SAM](https://docs.aws.amazon.com/serverless-application-model/latest/developerguide/)
-- [Salesforce CLI](https://developer.salesforce.com/docs/atlas.en-us.sfdx_cli_reference.meta/sfdx_cli_reference/cli_reference.htm)
+Want the diff on the PR before merging? Add a `sf ps plan --file "permissions/*.yml" --target-org prod` step to workflow 2, right after the login step, so reviewers see the change set that `apply` will carry out on merge.
 
 ## Versioning
 
@@ -502,13 +537,14 @@ gh release create v0.2.0 --target main --title v0.2.0 --notes "Add ps export"
 The plugin is layered so every command reuses the same core. Commands stay thin, services hold the orchestration, core holds the reusable primitives, and a thin adapter layer isolates the Salesforce SDK.
 
 - **Commands** (`src/commands/ps/`): oclif only. They parse flags, construct the service (wiring in the org adapter when the command needs one), render output, and set the exit code.
-- **Services** (`src/services/`): one per command (`check`, `validate`, `export`, `apply`, and `plan`). Each is a class built from its dependencies and inputs, with a parameterless `run()` that turns the core into a command's behavior. A service also declares the ports it needs from the outside, like the `OrgClient` interface its adapter implements.
+- **Services** (`src/services/`): one per command (`check`, `validate`, `export`, `apply`, and `plan`), plus `resolution`, which the org-facing ones share. Each is a class whose constructor takes only its dependencies (the org client, a confirmation callback), while the per-invocation inputs are `run()` parameters, so one instance serves any number of runs. A service also declares the ports it needs from the outside, like the `OrgClient` interface its adapter implements.
 - **Core** (`src/core/`): the reusable building blocks. Pure, with no `@salesforce/*` imports, so every piece is unit-testable on its own.
 - **Adapters** (`src/adapters/`): the boundary to the outside world. `ConnectionOrgClient` implements the `OrgClient` port (declared in services) with a Salesforce `Connection`, and owns all the SOQL and SObject detail. Services depend on the port, not the SDK, so they test against a fake and stay free of connection detail.
 
 | Core module | Responsibility |
 | --- | --- |
-| `model` | Shared domain types (assignment, org, diff). |
+| `model` | Shared domain types (assignment, org). |
+| `username`, `target-name` | The identifiers, owning the org's case-insensitive comparison so no caller has to remember it. |
 | `finding` | The finding type and code vocabulary, plus constructors, formatting, and counting. |
 | `schema` | The zod contract for a file, plus validation. |
 | `parse` | File text to an object, with YAML and duplicate-key errors. |
@@ -516,12 +552,32 @@ The plugin is layered so every command reuses the same core. Commands stay thin,
 | `serialize` | Canonical tuples back to a user-keyed YAML document (the inverse of `normalize`). |
 | `load` | Expand globs, run parse then validate then normalize per file, and merge by union. |
 | `resolve` | Pure rules that turn declared references and the org's answers into findings, plus id lookups for assigning. No SOQL: the adapter owns that. |
-| `diff` | The desired model vs. the org's current state, producing adds, removes, and unchanged. |
-| `mode` | Scope a diff to what a reconcile mode acts on, plus the drift it leaves alone. |
+| `diff` | The desired model vs. the org's current state, producing adds, removes, and unchanged. The `Diff` it returns also scopes itself to a reconcile mode, reporting what that mode acts on and the drift it leaves alone. |
 | `report` | Format a diff as a plan. |
-| `plan-file` | Serialize and parse a saved plan: the frozen change set `apply --plan` runs. |
 
-Commands are slices of one pipeline. `check` runs the **load** stage only, with no org. `validate` adds **resolve**: it looks the declared references up through the `OrgClient` port (the adapter builds the SOQL) and evaluates the org's answers with resolve's pure rules. `export` runs in the opposite direction: it **fetch**es the org's current assignments through the port and **serialize**s them straight back to YAML, skipping load entirely. `apply` is the full pipeline: load, resolve to ids, **fetch** current state, **diff**, then insert and delete through the Collections API per the mode (guarded by `--max-deletes` and a confirmation). `plan` is that same pipeline stopping before the DML: load, resolve to ids, **fetch** current state, **diff**, and report, the same preview `apply --dry-run` produces. `plan --out` freezes that resolved change set to a file, and `apply --plan` runs it verbatim, skipping load, resolve, and diff.
+Commands are slices of one pipeline. `check` runs the **load** stage only, with no org. `validate` adds **resolve**: it looks the declared references up through the `OrgClient` port (the adapter builds the SOQL) and evaluates the org's answers with resolve's pure rules. `export` runs in the opposite direction: it **fetch**es the org's current assignments through the port and **serialize**s them straight back to YAML, skipping load entirely. `apply` is the full pipeline: load, resolve to ids, **fetch** current state, **diff**, then insert and delete through the Collections API per the mode (guarded by `--max-deletes` and a confirmation). `plan` is that same pipeline stopping before the DML: load, resolve to ids, **fetch** current state, **diff**, and report, the same preview `apply --dry-run` produces.
+
+## Development
+
+```bash
+npm ci
+npm run build   # compile and lint
+npm test        # compile, then run the suite
+```
+
+The suite is black-box: every spec spawns the real `sf ps ...` binary. Install the Salesforce CLI first (`npm install -g @salesforce/cli`). The test run links this plugin into `sf` before the first spec and unlinks it at the end.
+
+### Test environment
+
+Tests take their parameters from the environment, never from a committed file. Copy the template and fill it in:
+
+```bash
+cp .env.example .env
+```
+
+| Variable | Required | What it is |
+| --- | --- | --- |
+| `PS_TARGET_ORG` | yes | Username or alias of an already-authenticated org. The `plan`, `apply`, and `export` specs run against it. |
 
 ## License
 

package/lib/adapters/connection-org-client.d.ts

@@ -1,18 +1,20 @@
 import { Connection } from '@salesforce/core';
-import { ActualAssignment, AssignmentFilter, AssignmentOutcome, AssignmentUpdate, DesiredAssignment, Kind, OrgTarget, OrgUser, ResolvedAddition, TargetRef } from '../core/index.js';
+import { ActualAssignment, AssignmentFilter, AssignmentOutcome, AssignmentUpdate, DesiredAssignment, OrgTarget, OrgUser, ResolvedAddition, TargetName, TargetRef, Username } from '../core/index.js';
 import { OrgClient } from '../services/adapters/index.js';
 /** Adapter backing OrgClient with a Salesforce Connection. autoFetchQuery pages past 2000 rows. */
 export declare class ConnectionOrgClient implements OrgClient {
     private readonly connection;
     constructor(connection: Connection);
-    findUsers(usernames: string[]): Promise<OrgUser[]>;
-    findTargets(kind: Kind, names: string[]): Promise<OrgTarget[]>;
+    findUsers(usernames: Username[]): Promise<OrgUser[]>;
+    findPermissionSets(names: TargetName[]): Promise<OrgTarget[]>;
+    findPermissionSetGroups(names: TargetName[]): Promise<OrgTarget[]>;
+    findPermissionSetLicenses(names: TargetName[]): Promise<OrgTarget[]>;
     listAssignments(filter?: AssignmentFilter): Promise<DesiredAssignment[]>;
     private listMemberships;
     private listLicenses;
-    currentAssignments(targets: TargetRef[]): Promise<ActualAssignment[]>;
-    private membershipAssignments;
-    private licenseAssignments;
+    listCurrentAssignments(targets: TargetRef[]): Promise<ActualAssignment[]>;
+    private listMembershipAssignments;
+    private listLicenseAssignments;
     addAssignments(additions: ResolvedAddition[]): Promise<AssignmentOutcome[]>;
     updateAssignments(updates: AssignmentUpdate[]): Promise<AssignmentOutcome[]>;
     removeAssignments(removals: ActualAssignment[]): Promise<AssignmentOutcome[]>;

package/lib/adapters/connection-org-client.d.ts.map

@@ -1 +1 @@
-{"version":3,"file":"connection-org-client.d.ts","sourceRoot":"","sources":["../../src/adapters/connection-org-client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAC9C,OAAO,EACH,gBAAgB,EAChB,gBAAgB,EAChB,iBAAiB,EACjB,gBAAgB,EAChB,iBAAiB,EACjB,IAAI,EACJ,SAAS,EACT,OAAO,EACP,gBAAgB,EAChB,SAAS,EACZ,MAAM,kBAAkB,CAAC;AAC1B,OAAO,EAAE,SAAS,EAAE,MAAM,+BAA+B,CAAC;AA6J1D,mGAAmG;AACnG,qBAAa,mBAAoB,YAAW,SAAS;IAC9B,OAAO,CAAC,QAAQ,CAAC,UAAU;gBAAV,UAAU,EAAE,UAAU;IAE7C,SAAS,CAAC,SAAS,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,OAAO,EAAE,CAAC;IAQlD,WAAW,CAAC,IAAI,EAAE,IAAI,EAAE,KAAK,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAS9D,eAAe,CAAC,MAAM,CAAC,EAAE,gBAAgB,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;YAkBvE,eAAe;YAoCf,YAAY;IAgBb,kBAAkB,CAAC,OAAO,EAAE,SAAS,EAAE,GAAG,OAAO,CAAC,gBAAgB,EAAE,CAAC;YA4BpE,qBAAqB;YAsBrB,kBAAkB;IAUnB,cAAc,CAAC,SAAS,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAkB3E,iBAAiB,CAAC,OAAO,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAkB5E,iBAAiB,CAAC,QAAQ,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;YAmB5E,KAAK;CAItB"}
+{"version":3,"file":"connection-org-client.d.ts","sourceRoot":"","sources":["../../src/adapters/connection-org-client.ts"],"names":[],"mappings":"AAAA,OAAO,EAAE,UAAU,EAAE,MAAM,kBAAkB,CAAC;AAC9C,OAAO,EACH,gBAAgB,EAChB,gBAAgB,EAChB,iBAAiB,EACjB,gBAAgB,EAChB,iBAAiB,EAEjB,SAAS,EACT,OAAO,EACP,gBAAgB,EAChB,UAAU,EACV,SAAS,EACT,QAAQ,EACX,MAAM,kBAAkB,CAAC;AAC1B,OAAO,EAAE,SAAS,EAAE,MAAM,+BAA+B,CAAC;AA4R1D,mGAAmG;AACnG,qBAAa,mBAAoB,YAAW,SAAS;IAC9B,OAAO,CAAC,QAAQ,CAAC,UAAU;gBAAV,UAAU,EAAE,UAAU;IAE7C,SAAS,CAAC,SAAS,EAAE,QAAQ,EAAE,GAAG,OAAO,CAAC,OAAO,EAAE,CAAC;IAUpD,kBAAkB,CAAC,KAAK,EAAE,UAAU,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAM7D,uBAAuB,CAAC,KAAK,EAAE,UAAU,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAMlE,yBAAyB,CAAC,KAAK,EAAE,UAAU,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAMpE,eAAe,CAAC,MAAM,CAAC,EAAE,gBAAgB,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;YAkBvE,eAAe;YAoBf,YAAY;IAYb,sBAAsB,CAAC,OAAO,EAAE,SAAS,EAAE,GAAG,OAAO,CAAC,gBAAgB,EAAE,CAAC;YAqBxE,yBAAyB;YAezB,sBAAsB;IAWvB,cAAc,CAAC,SAAS,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAkB3E,iBAAiB,CAAC,OAAO,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAkB5E,iBAAiB,CAAC,QAAQ,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;YAmB5E,KAAK;CAItB"}