33 lines
3.5 KiB
Markdown
33 lines
3.5 KiB
Markdown
# JSM test environment and acceptance preparation
|
|
|
|
Research date: 2026-09-24. No external tenant was provisioned or contacted with credentials during this research.
|
|
|
|
## Environment
|
|
|
|
No separate public mock/test Operations API host was found in the official reference. Use a dedicated test site's cloud ID with the ordinary Operations API. Basic authentication examples use `https://api.atlassian.com/jsm/ops/api/{cloudId}/v1`; OAuth 3LO uses a different gateway path. The existing adapter uses email/API-token basic authentication. Validate token type, scopes and both Operations and Jira directory access on the chosen site before writes. See the [Operations API introduction](https://developer.atlassian.com/cloud/jira/service-desk-ops/rest/v2/intro/).
|
|
|
|
Atlassian documents [Forge demo development sites](https://developer.atlassian.com/platform/forge/provision-a-demo-development-site/) with Enterprise editions including JSM, one active site per developer and a default 90-day lifetime. Provisioning does not require installing an app first:
|
|
|
|
```sh
|
|
npm install -g @forge/cli@latest
|
|
forge login
|
|
forge site provision
|
|
```
|
|
|
|
These sites are intended for development/testing; availability can be limited. Verify that Operations can be enabled and the required test people can be added before adopting one for acceptance. Meguri remains an external Rust service, not a Forge application. A separately provisioned JSM test site is the fallback.
|
|
|
|
Do not assume an organization's sandbox copies its on-call configuration: Atlassian lists Operations among [data not copied to sandboxes](https://support.atlassian.com/organization-administration/docs/what-data-is-copied-to-sandboxes/). This does not by itself establish that Operations cannot be configured there manually.
|
|
|
|
## Existing implementation and remaining evidence
|
|
|
|
`src/providers/jsm.rs` already implements schedule, escalation and routing publication, identity resolution, checkpoint recovery and read-back. The integration suite exercises it against a local fake HTTP server. These are implementation checks, not proof of compatibility with the live service.
|
|
|
|
1. Create a dedicated Operations team and two or three test users. Record site/cloud ID, team ID, account IDs and subscription capabilities. Keep credentials in deployment secrets.
|
|
2. Start a separate non-demo Meguri instance with a disposable database; application demo mode deliberately rejects real provider writes.
|
|
3. Verify read access to schedules and exact identity resolution. A person's email is a lookup key, not proof that JSM can notify them; their Atlassian account and notification settings must exist.
|
|
4. Publish a small weekly schedule and a partial replacement. Read the provider's final timeline and compare exact half-open assignments, including a DST boundary, against Meguri's publication.
|
|
5. Exercise immediate escalation, repeat settings, recipient variants and routing order on the actual subscription. Existing documentation/schema discrepancies (notably delay zero) remain acceptance gates, not permission to change scheduling semantics silently.
|
|
6. Repeat unchanged, simulate partial publication recovery, change a managed remote resource, verify drift blocking and explicit overwrite, then remove only resources created by this test.
|
|
|
|
Record redacted requests/responses, API dates, plan and observed limits. Keep ordinary CI on the local fake; live acceptance must be explicit and restricted to the dedicated test destination. See [testing.md](testing.md) for the provider acceptance contract.
|