ahmido
be314c577f
## Summary - rebuild the public Tenantial homepage around an evidence-first Microsoft tenant governance narrative - replace the old hero visual with a new static dashboard preview and add dedicated Trust Bar and Feature Pillars sections - update the shared public shell, navigation, footer, dark design tokens, assets, and homepage content to match the new brand direction - align website smoke coverage and Spec 400 artifacts with the rebuilt homepage ## Testing - not run in this pass - updated website smoke specs under apps/website/tests/smoke ## Note - `website-dev` was pushed to `origin` so the requested PR base exists remotely - the remote `website-dev` branch is an ancestor of `origin/dev`, so this PR may also show upstream `dev` history relative to that base Co-authored-by: Ahmed Darrazi <ahmed.darrazi@live.de> Reviewed-on: #387
56 lines
2.4 KiB
Markdown
56 lines
2.4 KiB
Markdown
# 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.
|