sf-plugin-permission-sets 0.3.1 → 0.5.0

package/LICENSE.md

@@ -0,0 +1,28 @@
+BSD 3-Clause License
+
+Copyright (c) 2026, Isaac Ferreira
+
+Redistribution and use in source and binary forms, with or without
+modification, are permitted provided that the following conditions are met:
+
+1. Redistributions of source code must retain the above copyright notice, this
+   list of conditions and the following disclaimer.
+
+2. Redistributions in binary form must reproduce the above copyright notice,
+   this list of conditions and the following disclaimer in the documentation
+   and/or other materials provided with the distribution.
+
+3. Neither the name of the copyright holder nor the names of its
+   contributors may be used to endorse or promote products derived from
+   this software without specific prior written permission.
+
+THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
+AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
+IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
+FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
+DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
+SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
+CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
+OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
+OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.

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.
@@ -21,9 +21,11 @@ Stop clicking through Setup to grant access. Commit a YAML file, open a PR, let
 - [Modes](#modes)
 - [Validations](#validations)
 - [Commands](#commands)
+- [GitHub Actions](#github-actions)
 - [Inspiration & equivalents](#inspiration--equivalents)
 - [Versioning](#versioning)
 - [Architecture](#architecture)
+- [Development](#development)
 
 ---
 
@@ -36,7 +38,7 @@ This plugin makes the desired state **declarative and reviewable**:
 - ✅ **Single source of truth:** the YAML in git is authoritative, and the org is reconciled to it.
 - ✅ **Plan before apply:** see exactly what will be added/removed before anything changes.
 - ✅ **Safe by default:** deletions are opt-in and guarded by a delete threshold.
-- ✅ **CI-native:** fully offline `check`, exit codes for gating, and `--json` on every command.
+- ✅ **CI-native:** `check` needs no org, exit codes for gating, and `--json` on every command.
 - ✅ **Flexible at the edges:** pick your file layout (by permission set or by user) and your sync mode.
 - ✅ **GitOps for access, the SFDX way:** assignments live in source and ship through the same git and CI pipeline as your metadata, instead of being clicked into Setup by hand.
 - ✅ **Fewer hands in Setup for higher environments:** because access is applied from git through CI, fewer people need direct Setup access in UAT and production, and every change is a reviewed pull request with a git audit trail.
@@ -53,33 +55,33 @@ Or pin a version:
 sf plugins install sf-plugin-permission-sets@x.y.z
 ```
 
-Requires Salesforce CLI (`sf`) and Node.js 18+.
+Requires Salesforce CLI (`sf`) and Node.js 20+.
 
 ## 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. Validate offline, no org needed:
-sf ps check --file "./permissions/*.yml"
+# 2. Edit the files, commit, open a PR. Check them, no org needed:
+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
 
-You point every command at one or more YAML files with `--file` (alias `-f`).
+`check`, `validate`, `plan`, and `apply` read one or more YAML files with `--file` (alias `-f`). (`export` writes YAML rather than reading it, so there `-f` is the output file.)
 
 Multiple files are merged into one model, so splitting by team is encouraged. The files contain **only declarative data**: knobs like sync mode and exclusions are CLI flags (see [Commands](#commands)), so there's no separate config format to learn yet. Each top-level key is unique within a file, and `check` flags duplicates.
 
@@ -191,15 +193,15 @@ A run performs three operations: **add** missing assignments, **update** changed
 
 ## Validations
 
-Every run checks the files first. `check` runs the offline checks with no org, and `validate` adds the org-side checks. When files merge, most overlaps are unions rather than errors.
+Every run checks the files first. `check` runs the file checks with no org, and `validate` adds the org-side checks. When files merge, most overlaps are unions rather than errors.
 
 | Situation | Checked by | Severity | Result |
 | --- | --- | :---: | --- |
-| Same user in two files with different targets | `check` (offline) | ✅ ok | Merged into one model, the point of slicing |
-| Same target listed twice for a user | `check` (offline) | ⚠️ warning | Deduped |
-| A user with no scopes, or an empty list | `check` (offline) | ⚠️ warning | Ignored as a no-op |
-| Same username key appears twice in one file | `check` (offline) | ❌ error | Rejected, the intent is ambiguous |
-| Declared user, permission set, group, or license missing or not unique | `validate` (online) | ❌ error | Run fails before any change |
+| 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 |
+| 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 |
 
 ## Commands
 
@@ -213,7 +215,7 @@ Every run checks the files first. `check` runs the offline checks with no org, a
 
 ### `sf ps check`
 
-Fully offline: runs in any CI job or pre-commit hook without org credentials.
+Needs no org: runs in any CI job or pre-commit hook without org credentials.
 
 ```
 USAGE
@@ -241,7 +243,7 @@ FLAGS
   -o, --target-org=<org>   (required) Org to resolve against.
   -f, --file=<glob>...     (required) YAML file(s) to read. Repeatable, globs expanded by the plugin.
 
-Runs all offline checks, then verifies that every user (active), permission set,
+Runs everything `check` does, then verifies that every user (active), permission set,
 group, and license referenced actually exists and resolves uniquely.
 ```
 
@@ -306,8 +308,8 @@ Next: sf ps apply -o prod -f "permissions/*.yml" --mode sync
 
 ```
 USAGE
-  $ sf ps apply -o <org> -f <glob>... [--mode <value>] [--max-deletes <n>]
-                [--dry-run] [--show-unchanged] [--no-prompt] [--json]
+  $ 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)
@@ -319,23 +321,152 @@ FLAGS
   --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).
+
 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.
 
 ### `sf ps export`
 
-Read-only. Snapshots the org's current assignments into a single YAML file you can commit and then feed back into the other commands.
+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.
 
 ```
 USAGE
-  $ sf ps export -o <org> --output-file <file> [--json]
+  $ sf ps export -o <org> [-f <file>] [--user <username>...]
+                 [--kind <scope>...] [--json]
 
 FLAGS
   -o, --target-org=<org>   (required) Org to read assignments from.
-  --output-file=<file>     (required) Path of the YAML file to write. Parent directories are created; an existing file is overwritten.
+  -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.
+  --kind=<scope>...         Only export these scopes: permissionSets | permissionSetGroups | permissionSetLicenses. Repeatable.
 ```
 
 It exports every assignable permission set, group, and license assignment held by active users, keyed by username, so the result is immediately valid input for `check`, `validate`, `plan`, and `apply`. Profile-owned permission sets and inactive users are skipped.
 
+With `--output-file` the command writes the file and prints a one-line summary. Omit the flag and the YAML goes to stdout instead, byte-for-byte identical to what the file would contain, so it pipes and diffs cleanly: in that mode only the document reaches stdout and warnings go to stderr, so there is nothing to strip. Under `--json` the envelope is the only thing on stdout, and when `--output-file` is omitted the document comes back in its `content` field.
+
+```bash
+# Diff the org's live state against a committed snapshot
+sf ps export -o prod | diff - permissions/prod.yml
+
+# Redirect a scoped snapshot to a file of your choosing
+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.
+
+```bash
+# Snapshot one team's permission sets and groups only
+sf ps export -o prod --output-file team.yml \
+  --user jdoe@acme.com --user asmith@acme.com \
+  --kind permissionSets --kind permissionSetGroups
+```
+
+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.
+
+## GitHub Actions
+
+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.
+
+**1. Check pull requests to main** (no org, no secrets):
+
+```yaml
+# .github/workflows/permissions-check.yml
+name: permissions-check
+
+on:
+  pull_request:
+    branches: [main]
+
+jobs:
+  check:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 20
+
+      - name: Install Salesforce CLI
+        run: npm install --global @salesforce/cli
+
+      - name: Install the plugin
+        run: sf plugins install sf-plugin-permission-sets
+
+      - name: Check the permission files
+        run: sf ps check --file "permissions/*.yml"
+```
+
+**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: 20
+
+      - 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
+name: permissions-apply
+
+on:
+  push:
+    branches: [main]
+
+jobs:
+  apply:
+    runs-on: ubuntu-latest
+    steps:
+      - uses: actions/checkout@v7
+      - uses: actions/setup-node@v7
+        with:
+          node-version: 20
+
+      - 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: Apply the assignments
+        run: sf ps apply --file "permissions/*.yml" --target-org prod --mode sync --no-prompt
+```
+
+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`.
+
+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.
+
 ## Inspiration & equivalents
 
 This plugin's command surface borrows ideas from tools you already know:
@@ -376,17 +507,14 @@ gh release create v0.2.0 --target main --title v0.2.0 --notes "Add ps export"
 | dist-tag | Published by | Install |
 | --- | --- | --- |
 | `latest` | manual release with a normal tag like `v1.2.0` | `sf plugins install sf-plugin-permission-sets` |
-| `next` | manual release with a hyphenated tag like `v1.3.0-beta.1` | `sf plugins install sf-plugin-permission-sets@next` |
 | `dev` | automatic on every push to `main` | `sf plugins install sf-plugin-permission-sets@dev` |
 
-The `next` tag is selected whenever the version contains a hyphen, not by GitHub's prerelease checkbox.
-
 ## Architecture
 
 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.
 
@@ -401,9 +529,33 @@ The plugin is layered so every command reuses the same core. Commands stay thin,
 | `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. |
 | `report` | Format a diff as a plan. |
 
-Commands are slices of one pipeline. `check` runs the offline **load** stage only. `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.
+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,14 +1,20 @@
 import { Connection } from '@salesforce/core';
-import { ActualAssignment, AssignmentOutcome, AssignmentUpdate, DesiredAssignment, Kind, OrgTarget, OrgUser, ResolvedAddition, TargetRef } from '../core/model.js';
-import { OrgClient } from '../services/adapters/org-client.js';
+import { ActualAssignment, AssignmentFilter, AssignmentOutcome, AssignmentUpdate, DesiredAssignment, OrgTarget, OrgUser, ResolvedAddition, TargetRef } 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[]>;
-    listAssignments(): Promise<DesiredAssignment[]>;
-    currentAssignments(targets: TargetRef[]): Promise<ActualAssignment[]>;
+    findPermissionSets(names: string[]): Promise<OrgTarget[]>;
+    findPermissionSetGroups(names: string[]): Promise<OrgTarget[]>;
+    findPermissionSetLicenses(names: string[]): Promise<OrgTarget[]>;
+    listAssignments(filter?: AssignmentFilter): Promise<DesiredAssignment[]>;
+    private listMemberships;
+    private listLicenses;
+    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,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,oCAAoC,CAAC;AA6J/D,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,IAAI,OAAO,CAAC,iBAAiB,EAAE,CAAC;IA8C/C,kBAAkB,CAAC,OAAO,EAAE,SAAS,EAAE,GAAG,OAAO,CAAC,gBAAgB,EAAE,CAAC;IA0DrE,cAAc,CAAC,SAAS,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAoB3E,iBAAiB,CAAC,OAAO,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;IAoB5E,iBAAiB,CAAC,QAAQ,EAAE,gBAAgB,EAAE,GAAG,OAAO,CAAC,iBAAiB,EAAE,CAAC;YAuB5E,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,SAAS,EACZ,MAAM,kBAAkB,CAAC;AAC1B,OAAO,EAAE,SAAS,EAAE,MAAM,+BAA+B,CAAC;AAgR1D,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;IAMlD,kBAAkB,CAAC,KAAK,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAMzD,uBAAuB,CAAC,KAAK,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAM9D,yBAAyB,CAAC,KAAK,EAAE,MAAM,EAAE,GAAG,OAAO,CAAC,SAAS,EAAE,CAAC;IAMhE,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"}