docs(screenconnect skill): clarify end goal — GuruRMM addon, BYO alternative to GuruConnect
Replace the thin "Future: GuruRMM integration" stub with a "Why this skill exists" section: ScreenConnect surfaces as a per-partner Integrations Center / addons-page entry, positioned as the bring-your-own alternative to GuruConnect (a partner already paying for ScreenConnect uses their licensed instance as the remote-access backend). Points at the mapped plan: SPEC-024, RMM_THOUGHTS Feature 7 + Refinement 7a, the Integrations Center roadmap item. Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
This commit is contained in:
@@ -93,15 +93,39 @@ surfacing it. It does NOT log expected/handled conditions - a missing extension
|
||||
method ("web method does not exist"), a rate-limit (429), the `raw` probe path, or
|
||||
selftest runs (`SC_SUPPRESS_ERRORLOG=1`) are skipped (see `_should_log_error`).
|
||||
|
||||
## Future: GuruRMM integration (Raw idea)
|
||||
## Why this skill exists: the GuruRMM addon integration (the end goal)
|
||||
|
||||
Tie this into GuruRMM (parallels the multi-vendor security thought, Feature 6):
|
||||
when a device is flagged for ScreenConnect in the RMM, GuruRMM looks up the
|
||||
device's client/site/tags and calls `build-installer` to produce a parameterized
|
||||
installer, then pushes it via the agent - so the device installs the correct SC
|
||||
client and self-places into the right Company/Site/Tag automatically. `set-
|
||||
properties` keeps the SC tags in sync when the RMM record changes. Capture/advance
|
||||
via RMM_THOUGHTS -> /shape-spec (needs Mike's go).
|
||||
This skill is the **verified connector prototype** for a GuruRMM addon, not a
|
||||
one-off CLI. The end goal is to surface ScreenConnect as a first-class, per-partner
|
||||
entry on the GuruRMM **Integrations Center / App Center** ("addons page"), so a
|
||||
partner can wire in their OWN paid ScreenConnect instance and the RMM drives it.
|
||||
|
||||
**Positioning - ScreenConnect is the bring-your-own alternative to GuruConnect.**
|
||||
GuruRMM's native remote-access product is **GuruConnect** (consumed via its
|
||||
integration contract - see `guru-rmm/docs/GURU_CONNECT_INTEGRATION.md`). A partner
|
||||
who is **already paying for ScreenConnect and does NOT want GuruConnect** enables
|
||||
the ScreenConnect addon instead and uses their existing licensed instance for
|
||||
remote access. Same RMM surface (the "remote control" device action, embedded/
|
||||
launched session), different provider behind it - selectable per partner on the
|
||||
addons page. It is an alternative remote-access backend, not an addition GuruConnect
|
||||
depends on.
|
||||
|
||||
**What this skill proves / ports into the server:** the parameterized access
|
||||
installer build (`build-installer` -> a pre-keyed URL whose repeated `c=` params
|
||||
self-tag the device into the right Company/Site/Tag with no SC-console step), the
|
||||
silent RMM push, and post-install control (`send-command`, `send-message`,
|
||||
`set-properties` to keep SC custom properties in sync as the RMM record changes).
|
||||
`sc_client.build_installer_url` + the control methods are what move server-side.
|
||||
|
||||
**Where the plan is mapped (all GuruRMM-side, needs Mike's go - status Raw):**
|
||||
- `docs/specs/SPEC-024-screenconnect-auto-deploy.md` - the auto-deploy mechanics
|
||||
(per-partner instance config, `c0..c7` slot mapping, scope toggles, dispatch).
|
||||
- `docs/RMM_THOUGHTS.md` **Feature 7** - parameterized deploy + control from the RMM.
|
||||
- `docs/RMM_THOUGHTS.md` **Refinement 7a** (Mike) - ScreenConnect as a per-partner
|
||||
App Center entry; generalizes to a "Remote Access" category (SC/TeamViewer/AnyDesk).
|
||||
- `docs/FEATURE_ROADMAP.md` **Integrations Center** - the unified addons UI surface.
|
||||
|
||||
Advance via RMM_THOUGHTS -> `/shape-spec`. Do NOT build until Mike gives the go.
|
||||
|
||||
## Reference
|
||||
|
||||
|
||||
Reference in New Issue
Block a user