[tests-only][full-ci] test(spaces): add acceptance test for creating a space with a caller-supplied id

[dj4oC]

Description

Adds acceptance-test coverage for creating a Space with a caller-supplied id through the Graph API.

• New step definition theUserCreatesASpaceWithIdUsingTheGraphApi in tests/acceptance/bootstrap/SpacesContext.php, allowing an id field in the create-space request body (the existing ...WithQuota... step only set name, driveType and quota).
• New scenario in tests/acceptance/features/apiSpaces/createSpace.feature that creates a project space with an explicit UUID and asserts the response's id, root.webDavUrl and webUrl all reflect the supplied UUID.

Related Issue

• Fixes [QA] Allow setting spaceIDs through graph API #11265

Motivation and Context

The Graph API already honors a caller-supplied space id on create — createDrive in services/graph/pkg/service/v0/drives.go forwards drive.Id to reva via the "spaceid" opaque (csr.Opaque = utils.AppendPlainToOpaque(csr.Opaque, "spaceid", *drive.Id)), implemented in #11256 (ticket #11235). No acceptance test exercised passing a custom id in the request body or asserted the server honors it, leaving this behavior unverified against regressions. This PR closes that gap.

Root cause of the gap: the only create-space step definition built a fixed body (name/driveType/quota) with no way to include an id, so no .feature scenario could cover the supplied-id path.

How Has This Been Tested?

• test environment: local static verification only — a full oCIS acceptance stack is not available in this authoring environment, so the live HTTP run is delegated to CI ([full-ci]).
• php -l tests/acceptance/bootstrap/SpacesContext.php — no syntax errors.
• behat --dry-run (apiSpaces suite) — the new scenario's 5 steps all bind to step definitions (0 undefined, 0 ambiguous for this scenario); the new step regex is unambiguous against existing ones. (The suite reports 4 pre-existing undefined steps for an unrelated ...requests these endpoints ... with basic auth step, not touched here.)
• The JSON-schema match block was validated as well-formed JSON, and the id pattern ^%user_id_pattern%\$<uuid>$ was verified to match the correct <provider-uuid>$<supplied-uuid> form and reject a wrong space UUID.
• test case: admin user creates a space with a caller-supplied id via the Graph API → expects 201 and id/webDavUrl/webUrl containing the supplied UUID 11111111-1111-4111-8111-111111111111.

Architecture notes

Test-only, additive change. It introduces no service, topology, dependency, or API-contract change — the underlying feature already shipped in #11256. The new step reuses the existing GraphHelper::createSpace(...) helper (which already accepts a raw body) and mirrors the existing create-space step exactly, including addToCreatedSpace(...) bookkeeping. Assertion reuses the established %user_id_pattern% / %base_url% inline-code + JSON-schema pattern idiom already used elsewhere in the suite.

Documentation

• Changelog fragment: not applicable — test-only change (consistent with recent [tests-only][full-ci] PRs such as [tests-only][full-ci] test: add oc:spaceid to REPORT response acceptance tests #12489, [tests-only][full-ci] test: add spaceId to remoteItem in incoming shares #12485, [tests-only][full-ci]test(cli): add clean-orphaned-grants CLI test scenarios #12470, which add no changelog fragment).
• REUSE 3.3 headers: not applicable — repo REUSE.toml licenses path = "**" globally; no new files, and modified files need no inline header.
• Admin/end-user docs: not applicable (no user-visible behavior change).
• WCAG 2.2 / OTel: not applicable (no UI, no new metrics).

Types of changes

• Bug fix (non-breaking change which fixes an issue)
• New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to change)
• Technical debt
• Tests only (no source changes)

Checklist:

• Code changes
• Unit tests added
• Acceptance tests added
• Documentation ticket raised

---

Reviewer notes (automated pipeline)

• Pre-flight review (security/stability/performance/test-coverage): no blocking findings. No non-blocking findings. No production code touched; no auth/permission/network/filesystem/dependency surface introduced (adversarial self-scan clean).
• Coverage: the new step definition is glue code fully exercised by the new scenario when the acceptance test runs; there is no independently unit-testable new logic. Effective coverage of new code once CI runs the scenario is ~100%.
• Bug-fix iterations: 0 (no failures encountered in static verification).
• Risk level: Low — additive, isolated test-only change; blast radius limited to one new scenario.

🤖 Generated with Claude Code

https://claude.ai/code/session_01WsjpVPM1fMMD5DkxWE7575

---

Generated by Claude Code

[kw-security]

✅ Snyk checks have passed. No issues have been found so far.

Status	Scan Engine	Critical	High	Medium	Low	Total (0)
✅	Open Source Security	0	0	0	0	0 issues
✅	Licenses	0	0	0	0	0 issues
✅	Code Security	0	0	0	0	0 issues

💻 Catch issues earlier using the plugins for VS Code, JetBrains IDEs, Visual Studio, and Eclipse.