Ebbe BaßandClaude Sonnet 5.5
24de5878ed
Includes the BMAD install config, the initiative ticket tree, the portal context-resources scripts, and the .gitignore change that tracks BMAD files (generated _bmad/render/ is ignored). Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01Sk72AxLwQnYttF6VFSxQLt
4.8 KiB
4.8 KiB
topic, updated
| topic | updated |
|---|---|
| ping-mee self-service portal | 2026-10-15T09:24 |
- (event) Create intent; coaching/fast mode not yet chosen. Stakes not yet read.
- (decision) Context: ping-mee.de is the user's large homelab (Jellyfin etc.); users authenticate against homelab Active Directory (domain ping-mee.local).
- (decision) Scope v1 (user words): users self-edit email, displayname, name, surname, profile picture, phone number.
- (decision) Scope v1: announcement feature so admin can announce planned downtimes and changes.
- (decision) Design: resembles classic Microsoft web UI. Login via LDAPS.
- (event) User supplied context-resources/*.ps1: existing profile-picture pipeline (fileshare source -> AD thumbnailPhoto/jpegPhoto/photo at 96px <=100KB -> Windows logon script builds account picture sizes, 448px HQ copy from share).
- (decision) Users: family and friends, ~10 people. Yet wants polished and protected 'for big deployments' (tension with right-sizing; to probe).
- (decision) Pictures: portal drops files on the fileshare (existing sync task does the AD write); portal renames to .jpg if not already named so. Portal does NOT write thumbnailPhoto itself.
- (decision) AD writes (other attributes): portal uses a dedicated service account with delegated privileges.
- (decision) Announcements: delivered by e-mail AND shown on an announcement page in the portal.
- (decision) Design: Office 365 (Fluent) look, not OWA 2010/Aero.
- (decision) Stakes: homelab use first, keep option to deploy elsewhere someday (=> no hardcoded domain/OU/share paths).
- (decision) Everything configurable, nothing baked in (domain, OU, paths, groups, SMTP, theme). Portal reachable from the INTERNET. No multi-domain. Admin UI wanted: upload backgrounds, change themes, settings.
- (decision) Pictures: portal converts to JPEG, scales/sizes to need; user message 'updated within ~2 hours' (sync-task latency).
- (decision) Writable scope: OU=Clients,OU=Organisation,DC=ping-mee,DC=local (configurable). Attributes: sn, displayName, givenName, mail, name, cn. Mail change requires confirmation e-mail.
- (assumption) GAP: phone number was in the original request but is not in the attribute list (telephoneNumber/mobile?). Also name/cn are the RDN: changing needs ModifyDN, not attribute modify.
- (decision) Announcements: publishers = members of a configurable AD group; SMTP server configurable (IONOS); opt-out/opt-in for e-mails wanted; one-way text primary, scheduled downtime window / severity / expiry as OPTIONAL features.
- (decision) Deployment: Docker container on a Linux box.
- (decision) Phone: both telephoneNumber and mobile. name and cn REMOVED from concept (no RDN renames).
- (decision) Behind reverse proxy (TLS there). Login throttling wanted. Asked: authentik IdP between AD and portal as option (user has an authentik server).
- (decision) Scope: ship everything (user: not a rational project, homelab is oversized by design). No phasing imposed; sequencing left to downstream.
- (decision) E-mail announcements: default opt-IN; on opt-out user is told they won't get downtime notifications and can opt back in via portal.
- (decision) Secrets via Docker environment variables.
- (decision) NEW SCOPE: password change by users at any time (admin currently resets manually) - core success criterion. Success = no manual password resets AND one clean all-in-one package solving these homelab problems.
- (decision) Password: users can CHANGE only (current+new); reset stays a manual admin process (out of scope). E-mail change requires current password + confirmation e-mail. Users with expired/must-change passwords can still log in (mechanism unresolved with OIDC).
- (decision) Login via OIDC (authentik) for initial authentication only; all writes stay LDAPS with service account. Prefers OIDC over LDAPS login.
- (decision) Problems solved: password change, profile info, profile pictures, announcement channel. 'Clean' = no good solution exists for these today; one all-in-one package. PowerShell scripts (sync, logon, registry) stay.
- (decision) Mode: FAST PATH chosen. Draft brief with [ASSUMPTION] tags.
- (assumption) Success criterion tension: forgotten passwords still need manual reset by admin, so 'no manual password work' only holds for known-password changes.
- (assumption) Expired-password login: authentik/AD OIDC login likely fails for expired passwords; mechanism needs design.
- (decision) Expired-password behavior with authentik unknown; to be tested. Password change confirmed: user enters current+new in portal, applied over LDAPS.
- (decision) Security success criterion: no injections, no session takeover, no cross-user read/write, throttled logins.
- (change) Draft v1 written: brief.md + addendum.md; security criterion made concrete, open question on expired passwords reworded.
- (event) Polish pass (bmad-review structure+prose) applied; brief status set to final.