ahmido
bbb1cb0982
## Summary <!-- Kurz: Was ändert sich und warum? --> ## Spec-Driven Development (SDD) - [ ] Es gibt eine Spec unter `specs/<NNN>-<feature>/` - [ ] Enthaltene Dateien: `plan.md`, `tasks.md`, `spec.md` - [ ] Spec beschreibt Verhalten/Acceptance Criteria (nicht nur Implementation) - [ ] Wenn sich Anforderungen während der Umsetzung geändert haben: Spec/Plan/Tasks wurden aktualisiert ## Implementation - [ ] Implementierung entspricht der Spec - [ ] Edge cases / Fehlerfälle berücksichtigt - [ ] Keine unbeabsichtigten Änderungen außerhalb des Scopes ## Tests - [ ] Tests ergänzt/aktualisiert (Pest/PHPUnit) - [ ] Relevante Tests lokal ausgeführt (`./vendor/bin/sail artisan test` oder `php artisan test`) ## Migration / Config / Ops (falls relevant) - [ ] Migration(en) enthalten und getestet - [ ] Rollback bedacht (rückwärts kompatibel, sichere Migration) - [ ] Neue Env Vars dokumentiert (`.env.example` / Doku) - [ ] Queue/cron/storage Auswirkungen geprüft ## UI (Filament/Livewire) (falls relevant) - [ ] UI-Flows geprüft - [ ] Screenshots/Notizen hinzugefügt ## Notes <!-- Links, Screenshots, Follow-ups, offene Punkte --> Co-authored-by: Ahmed Darrazi <ahmeddarrazi@adsmac.local> Reviewed-on: #53
51 lines
2.1 KiB
Markdown
51 lines
2.1 KiB
Markdown
# Research T186 — settings_apply capability verification (LEGACY / DEPRECATED)
|
|
|
|
> 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.
|