Disable paging and raise pageSize on NinjaOne array-mode datastreams

[Deenk]

📋 Summary

The 6 datastreams that hit NinjaOne's array endpoints (/v2/devices, /v2/organizations, /v2/locations, plus the 3 scoped variants) were configured with token-mode paging reading metadata.next_page_token from the response. That field doesn't exist for these specific endpoints. NinjaOne returns a plain JSON array with no envelope or pagination headers, so paging silently stopped after page 1, capping users at 1000 devices.

As I understand it, the SquaredUp Web API plugin has no paging mode that fits NinjaOne's pattern of "last item's id as the next cursor" (verified against the API spec, live API response, and the Web API paging support doc). Fixing this properly needs a framework change I think.

As a stopgap, switch to mode: none and request pageSize: 10000 in getArgs. NinjaOne accepts arbitrary pageSize values without error in testing, though we couldn't verify the actual server-side cap on a small test tenant. This matches the precedent already used in activities.json.

---

🔗 Related issue(s)

---

🧩 Plugin details

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

---

⚠️ Breaking changes

Does this PR introduce any breaking changes?

• No
• Yes (please describe):

If yes, describe:

• What breaks
• Who is impacted
• Any migration steps

---

📚 Documentation

• Documentation updated
• 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/NinjaOne/v1

📋 Results

Step	Status
Validation	✅ Passed
Deployment	🚀 Deployed

🔍 Validation Details

✅ ninja-one

{
  "valid": true,
  "pluginName": "ninja-one",
  "pluginType": "cloud",
  "summary": {
    "Data Streams": 37,
    "Import Definitions": 1,
    "UI Configuration": true,
    "Has Icon": true,
    "Has Default Content": true,
    "Config Validation": false,
    "Custom Types": true
  }
}

[clarkd]

As I understand it, the SquaredUp Web API plugin has no paging mode that fits NinjaOne's pattern of "last item's id as the next cursor" (verified against the API spec, live API response, and the Web API paging support doc). Fixing this properly needs a framework change I think.

@WaynePlummer can advise here

[claude]

🔴 This PR modifies 6 data stream files under plugins/NinjaOne/v1/dataStreams/ but does not bump the version in plugins/NinjaOne/v1/metadata.json (still at 1.1.9). Per the repo's review guidance, any change inside a plugin directory must include a corresponding metadata.json version bump; since this is a behavior-affecting paging fix, please add at least a patch bump (e.g. 1.1.9 -> 1.1.10) before merging.

Extended reasoning...

What the bug is

This PR changes runtime behavior of six NinjaOne data streams (devices.json, locationDevices.json, locations.json, organizationDevices.json, organizationLocations.json, organizations.json) by switching their paging mode from token to none and adding a pageSize: 10000 query arg. However, plugins/NinjaOne/v1/metadata.json is not modified by the PR and its version field still reads 1.1.9.

Why this matters

The repo's review instructions are explicit: "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." This is a hard rule, not a stylistic preference — without a version bump, downstream consumers cannot distinguish the fixed plugin from the broken pre-fix one, and the plugin distribution/release pipeline relies on the version field as its sole signal that the contents have changed.

Why existing checks don't catch it

The PR's automated Plugin PR Summary check reports Validation: ✅ Passed and Deployment: 🚀 Deployed, so the CI bot does not enforce the version-bump rule. The breaking-changes checkbox is set to "No", which is consistent with a patch bump (not a major/folder bump), but a patch bump is still required.

Impact

Once merged as-is, a user upgrading the plugin would receive the new paging behavior under an unchanged version number — making rollback decisions, support triage, and changelog tracking harder. Any downstream tooling keyed off the version (e.g. Has been updated since vX.Y.Z) will incorrectly report no change.

Step-by-step proof

1. Open plugins/NinjaOne/v1/metadata.json on this branch — version is "1.1.9".
2. Inspect the PR's changed-files list (6 files) — none of them is metadata.json.
3. Inspect any of the six diffs (e.g. devices.json lines 8-10) — the paging block was rewritten from mode: token with pageSize/in/out to mode: none, and getArgs now carries pageSize: 10000. This is a clear behavior change.
4. Per the repo guidance, this requires version to advance to at least 1.1.10. It has not.

How to fix

Bump plugins/NinjaOne/v1/metadata.json version from 1.1.9 to 1.1.10 (patch bump; no breaking change per the PR checkbox) and include it in this PR.

[WaynePlummer]

the API

Shame - @Deenk: can you point me at the API docs for this and I'll raise a JIRA for us to add support. Cheers