Add configValidation to DattoRMM plugin

[TimWheeler-SQUP]

📋 Summary

Adds a configValidation.json to the DattoRMM plugin so users get a connection test step during plugin setup. It validates the Base URL, API Key, and API Secret by exercising the existing importSites data stream (calls api/v2/account/sites).

---

🔗 Related issue(s)

---

🧩 Plugin details

• Plugin name: Datto RMM
• Type of change:
  • Bug fix
  • New datastream
  • Enhancement to existing datastream
  • Performance improvement
  • Documentation / metadata / logo
  • Other (please describe): Adds configValidation step

---

⚠️ Breaking changes

Does this PR introduce any breaking changes?

• No
• Yes (please describe):

---

📚 Documentation

• No documentation changes needed

---

✅ Checklist

• No secrets or credentials included
• Plugin, datastream and UI naming follow SquaredUp guidelines
• I agree to the Code of Conduct

[github-actions]

🧩 Plugin PR Summary

📦 Modified Plugins

• plugins/DattoRMM/v1

📋 Results

Step	Status
Validation	✅ Passed
Deployment	🚀 Deployed

🔍 Validation Details

✅ datto-rmm

{
  "valid": true,
  "pluginName": "datto-rmm",
  "pluginType": "cloud",
  "summary": {
    "Data Streams": 4,
    "Import Definitions": 1,
    "UI Configuration": true,
    "Has Icon": true,
    "Has Default Content": true,
    "Config Validation": true,
    "Custom Types": true
  }
}

[clarkd]

Claude should flag this too but you'll need to bump the version number - otherwise looks good!

[clarkd]

@claude review this

[claude]

🔴 This PR adds a new file inside the plugin directory (plugins/DattoRMM/v1/configValidation.json) but does not bump the version field in plugins/DattoRMM/v1/metadata.json (still 1.0.1). Per repo conventions, any change inside a plugin directory must include a version bump so users receive the update on their next plugin refresh — please bump it (e.g. to 1.0.2).

Extended reasoning...

What the bug is

The PR introduces a new file plugins/DattoRMM/v1/configValidation.json to add a connection-test step for the Datto RMM plugin. However, the accompanying plugins/DattoRMM/v1/metadata.json still has "version": "1.0.1", unchanged from before. The repository's review conventions explicitly require that any diff touching files inside a plugin directory include a corresponding version bump in metadata.json.

How it manifests / why the existing code doesn't prevent it

Plugin distribution systems typically use the version field in metadata.json as the trigger to deliver updated plugin assets to end users on refresh. Without a version bump, the validation pipeline still passes (as seen in the bot's summary comment showing Config Validation: true), and the new file is technically present in the repo, but downstream consumers who already have the plugin at 1.0.1 will see no version change and may not pick up the new configValidation.json on their next refresh. The validation tooling checks structural correctness of the new file but does not enforce the version-bump convention, so this slips through CI.

Impact

End users of the Datto RMM plugin will not receive the new connection-test step — defeating the entire purpose of this PR — even though the file is merged. The feature is effectively dark until the version is bumped in a follow-up commit.

How to fix

In plugins/DattoRMM/v1/metadata.json, change line 4 from "version": "1.0.1" to "version": "1.0.2" (or a higher appropriate semver) and include that change in this PR.

Step-by-step proof

1. The PR diff shows exactly one changed file: plugins/DattoRMM/v1/configValidation.json (new file, 11 lines). No other files are modified.
2. plugins/DattoRMM/v1/configValidation.json resides inside the plugin directory plugins/DattoRMM/v1/.
3. Reading plugins/DattoRMM/v1/metadata.json at line 4 shows "version": "1.0.1" — unchanged.
4. The repository review instructions state: "Any diff that touches files inside a plugin directory must include a corresponding change to metadata.json that increases the version field. If no version bump is present, assume the task is unfinished and prompt to add one."
5. Conditions (2) and (3) together violate that rule, so the version must be incremented before merge.