sf-plugin-permission-sets 0.0.0-dev.46 → 0.0.0-dev.48
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 +5 -6
- package/package.json +1 -1
package/README.md
CHANGED
|
@@ -53,7 +53,7 @@ Or pin a version:
|
|
|
53
53
|
sf plugins install sf-plugin-permission-sets@x.y.z
|
|
54
54
|
```
|
|
55
55
|
|
|
56
|
-
Requires Salesforce CLI (`sf`) and Node.js
|
|
56
|
+
Requires Salesforce CLI (`sf`) and Node.js 20+.
|
|
57
57
|
|
|
58
58
|
## Quick start
|
|
59
59
|
|
|
@@ -79,7 +79,7 @@ sf ps apply --file "./permissions/*.yml" --target-org prod --mode sync
|
|
|
79
79
|
|
|
80
80
|
## Permission files
|
|
81
81
|
|
|
82
|
-
|
|
82
|
+
`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.)
|
|
83
83
|
|
|
84
84
|
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.
|
|
85
85
|
|
|
@@ -425,11 +425,8 @@ gh release create v0.2.0 --target main --title v0.2.0 --notes "Add ps export"
|
|
|
425
425
|
| dist-tag | Published by | Install |
|
|
426
426
|
| --- | --- | --- |
|
|
427
427
|
| `latest` | manual release with a normal tag like `v1.2.0` | `sf plugins install sf-plugin-permission-sets` |
|
|
428
|
-
| `next` | manual release with a hyphenated tag like `v1.3.0-beta.1` | `sf plugins install sf-plugin-permission-sets@next` |
|
|
429
428
|
| `dev` | automatic on every push to `main` | `sf plugins install sf-plugin-permission-sets@dev` |
|
|
430
429
|
|
|
431
|
-
The `next` tag is selected whenever the version contains a hyphen, not by GitHub's prerelease checkbox.
|
|
432
|
-
|
|
433
430
|
## Architecture
|
|
434
431
|
|
|
435
432
|
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.
|
|
@@ -450,9 +447,11 @@ The plugin is layered so every command reuses the same core. Commands stay thin,
|
|
|
450
447
|
| `load` | Expand globs, run parse then validate then normalize per file, and merge by union. |
|
|
451
448
|
| `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. |
|
|
452
449
|
| `diff` | The desired model vs. the org's current state, producing adds, removes, and unchanged. |
|
|
450
|
+
| `mode` | Scope a diff to what a reconcile mode acts on, plus the drift it leaves alone. |
|
|
453
451
|
| `report` | Format a diff as a plan. |
|
|
452
|
+
| `plan-file` | Serialize and parse a saved plan: the frozen change set `apply --plan` runs. |
|
|
454
453
|
|
|
455
|
-
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.
|
|
454
|
+
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.
|
|
456
455
|
|
|
457
456
|
## License
|
|
458
457
|
|
package/package.json
CHANGED