ahmido bbb1cb0982 docs: deprecate .specify specs and update references (#53 )

## 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

2026-01-10 21:40:46 +00:00

2.1 KiB

Raw Blame History

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

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

GET /deviceManagement/configurationPolicies/{id}

Fetch settings subresource:

GET /deviceManagement/configurationPolicies/{id}/settings

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

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

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

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.
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.

2.1 KiB Raw Blame History