ahmido be314c577f Spec 400: rebuild Tenantial homepage visuals (#387 )

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

2026-05-18 14:38:11 +00:00

2.4 KiB

Raw Permalink Blame History

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

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.4 KiB Raw Permalink Blame History