sf-plugin-permission-sets 0.0.0-dev.66 → 0.0.0-dev.68
This diff represents the content of publicly available package versions that have been released to one of the supported registries. The information contained in this diff is provided for informational purposes only and reflects changes between package versions as they appear in their respective public registries.
- package/README.md +8 -8
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -1,6 +1,6 @@
|
|
|
1
1
|
# sf-plugin-permission-sets
|
|
2
2
|
|
|
3
|
-
[](https://www.npmjs.com/package/sf-plugin-permission-sets) [](https://npmjs.org/package/sf-plugin-permission-sets) [](https://semver.org/#spec-item-4) [](https://raw.githubusercontent.com/zaclummys/sf-plugin-permission-sets/main/LICENSE.
|
|
3
|
+
[](https://www.npmjs.com/package/sf-plugin-permission-sets) [](https://npmjs.org/package/sf-plugin-permission-sets) [](https://semver.org/#spec-item-4) [](https://raw.githubusercontent.com/zaclummys/sf-plugin-permission-sets/main/LICENSE.md)
|
|
4
4
|
|
|
5
5
|
> Declarative, GitOps-style management of **permission set assignments** for Salesforce orgs.
|
|
6
6
|
> Define who gets what in version-controlled YAML. The plugin reconciles your org to match it: `plan` then `apply`, just like Terraform.
|
|
@@ -61,22 +61,22 @@ Requires Salesforce CLI (`sf`) and Node.js 20+.
|
|
|
61
61
|
|
|
62
62
|
```bash
|
|
63
63
|
# 1. Bootstrap YAML from an existing org (so you don't start from scratch)
|
|
64
|
-
sf ps export --target-org dev --output-file permissions.yml
|
|
64
|
+
sf ps export --target-org dev --output-file permissions/dev.yml
|
|
65
65
|
|
|
66
66
|
# 2. Edit the files, commit, open a PR. Check them, no org needed:
|
|
67
|
-
sf ps check --file "
|
|
67
|
+
sf ps check --file "permissions/*.yml"
|
|
68
68
|
|
|
69
69
|
# 3. Validate against a real org (do the users/permission sets exist?)
|
|
70
|
-
sf ps validate --file "
|
|
70
|
+
sf ps validate --file "permissions/*.yml" --target-org dev
|
|
71
71
|
|
|
72
72
|
# 4. See what would change
|
|
73
|
-
sf ps plan --file "
|
|
73
|
+
sf ps plan --file "permissions/*.yml" --target-org dev
|
|
74
74
|
|
|
75
75
|
# 5. Apply it (additive by default, only adds)
|
|
76
|
-
sf ps apply --file "
|
|
76
|
+
sf ps apply --file "permissions/*.yml" --target-org dev
|
|
77
77
|
|
|
78
78
|
# 6. Full reconcile, including removals (opt-in)
|
|
79
|
-
sf ps apply --file "
|
|
79
|
+
sf ps apply --file "permissions/*.yml" --target-org prod --mode sync
|
|
80
80
|
```
|
|
81
81
|
|
|
82
82
|
## Permission files
|
|
@@ -514,7 +514,7 @@ gh release create v0.2.0 --target main --title v0.2.0 --notes "Add ps export"
|
|
|
514
514
|
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.
|
|
515
515
|
|
|
516
516
|
- **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.
|
|
517
|
-
- **Services** (`src/services/`): one per command (`check`, `validate`, `export`, `apply`, and `plan`). Each is a class
|
|
517
|
+
- **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.
|
|
518
518
|
- **Core** (`src/core/`): the reusable building blocks. Pure, with no `@salesforce/*` imports, so every piece is unit-testable on its own.
|
|
519
519
|
- **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.
|
|
520
520
|
|
package/package.json
CHANGED