# Research T186 — settings_apply capability verification (LEGACY / DEPRECATED)

> **Status:** Superseded  
> **Last reviewed:** 2026-04-30  
> **Use for:** Historical investigation context only if a later Settings Catalog write-path regression needs provenance  
> **Do not use for:** Active feature research or current implementation truth

> DEPRECATED: Do not add new research notes under `.specify/`.
> Active feature research should live under `specs/<NNN>-<slug>/`.
> Legacy history lives under `spechistory/`.

Objective
---------
Verify whether the Microsoft Graph endpoint `deviceManagement/configurationPolicies/{id}/settings` accepts writes (POST/PUT) for applying Settings Catalog settings and document the exact request body shape and required `@odata.type` values.

Context
-------
Logs show `PATCH` to the parent resource fails with `ModelValidationFailure: Cannot apply PATCH to navigation property 'settings'`. A fallback implemented in RestoreService attempts to `POST` to `.../{id}/settings` but tenant behavior is inconsistent (some tenants return `NotSupported`).

Verification Steps
------------------
1. Choose a test tenant and service principal that reflect the production app permissions.
2. Fetch a sample Settings Catalog policy:

```http
GET /deviceManagement/configurationPolicies/{id}
```

3. Fetch settings subresource:

```http
GET /deviceManagement/configurationPolicies/{id}/settings
```

4. Construct a minimal settings payload (single setting) including `settingInstance.@odata.type` and try POST:

```http
POST /deviceManagement/configurationPolicies/{id}/settings
Content-Type: application/json

[ { <setting object with settingInstance and @odata.type> } ]
```

5. If POST fails, record full response body and headers (request-id, client-request-id). Try alternative shapes (e.g. POST `{ "settings": [...] }`) and different methods (PUT) if documented.

6. Capture any success responses and validate resulting settings in the portal or via subsequent GET.

Deliverables
------------
- `research_t186.md` (this file) populated with observed request/response bodies and decision (A: supported — include exact body_shape; B: unsupported — document fallback and admin instructions).
- If supported, proposed `config/graph_contracts.php` entry finalized and tests updated.

Notes
-----
- Do not include secrets in this document. Paste only non-sensitive request/response metadata and request ids.
