Features #185
stängdFeatures #178: Samordning: generiska föreningsspecifika klippkort
Fastställ behörigheter och deltagarval för familjekort
100%
Beskrivning
Refinement. DoD: besluta hur kortägare, den som klipper och deltagare hålls isär; hur förälder väljer flera barn; vem får använda kortet och hur åtkomst beviljas/återkallas. Beskriv minsta deltagaruppgifter och kontokrav utan att anta att barn måste ha egna konton. Återanvänd #130/#132. Dokumenterat beslut och snävt implementationsärende krävs; ingen kod eller verkliga personuppgifter här.
Acceptanskriterier
Dokumenterat beslut skiljer kortägare, utförande konto och deltagare. Första releasens lagring, synlighet, behörighet och återkallelse för deltagaruppgifter är uttryckligt avgränsade utan krav på barnkonto eller antagen vårdnad. Eventuellt senare familjeregister separeras till ett snävt implementationsärende. Ingen kod, driftsättning eller verklig persondata i #185.
Testresultat
PASS: användaren godkände avgränsningen 2026-09-21; beslutsdokument och logisk modell uppdaterade i 1245b70; PlantUML renderade utan fel och bilden granskades visuellt. Ingen kod, migration, driftändring eller verklig persondata ingår.
CA Uppdaterad av Codex API för 22 dagar sedan
Modellförslag #179 håller ägare/operator/deltagare separat. Refinement behöver omfatta livscykel och gallring av kopplingarna, inte bara namn: user/köp/actor/deltagarreferenser kan fortsatt identifiera person. Återanvänd befintligt dataskyddsarbete; inga nya lagringstider beslutade i modellen.
CA Uppdaterad av Codex API för 22 dagar sedan
Granskat befintlig users/user_profiles och artikelstyrda personfält. Förslag i docs/architecture/family-card-refinement-185.md: återanvänd vuxens konto, separata deltagare utan krav på barnkonton; första version endast kortägaren som operatör, egen förenings-/kontoavgränsad deltagarlista. Detta är FÖRSLAG, inte godkänt beslut. Behöver svar om annan vuxen måste kunna nyttja samma kort via eget konto från start. Även deltagarbehörighet/livscykel behöver beslut. Inga schema-/driftändringar, inga verkliga deltagaruppgifter eller nya lagringstider.
CA Uppdaterad av Codex API för 22 dagar sedan
Användaren godkänner att kortdelning via andra vuxnas egna konton ingår från första versionen. Förslaget med endast ägare som operatör ersätts. Avser ett bestämt kort, inbjudan/acceptans, saldo och nyttjande, ingen vidaredelegering, återkallbart. Den obesvarade frågan om tillgång till ägarens sparade barn är INTE beslutad; automatisk sådan åtkomst ska inte ges. Namn och födelseår per barn behövs för LOK-relevant aktivitet enligt användarens förtydligande.
CA Uppdaterad av Codex API för 22 dagar sedan
Första versionens modell uppdaterad med punch_card_invitations och punch_card_access samt dokumenterade spärrar för mottagare, engångstoken, återkallelse och samtidighet. docs/architecture/family-card-refinement-185.md och punch-cards-179.md uppdaterade. Diagramkälla punch-cards-179.puml omrenderad och bild visuellt kontrollerad. #190–192 registrerade som separata implementationer. Ingen kod/migration/driftändring; deltagaråtkomst fortfarande öppen och delas inte automatiskt.
CA Uppdaterad av Codex API för 22 dagar sedan
Användaren godkänner att annan målsman kan få tillgång till utvalda barns namn/födelseår för deltagarval via separat deltagarbehörighet. Ingen automatisk redigering eller full historik. Senaste förtydligande: på kortet behöver man inte se vilka som deltagit, utan kortägaren räcker. Deltagarregistrering/LOK och intern spårbarhet hålls separata från kortvisningen. Uppdaterat docs/architecture/family-card-refinement-185.md.
CA Uppdaterad av Codex API för 20 dagar sedan
Avstämning 2026-09-11: nästa implementationssteg är #241 under #186, enbart review-kontrakt och servervalidering per träningsenhet i blandad checkout med isolerade syntetiska tester. Kortägare, utförande konto och deltagare hålls isär; namn/födelseår följer artikelns uppgiftskrav, inga telefonuppgifter. Befintliga #164/#166 återanvänds, inte dupliceras. #190-192 ligger kvar separat för kortdelning; sådan delning ger inte automatiskt barnuppgiftsåtkomst. #185 lämnas öppet: livscykel/åtkomst för sparade deltagare och delad vårdnad är inte avgjorda av denna avgränsning. #188 kvarstår för aktivitet/tränarbekräftelse. Ingen kod, driftsättning eller insamling aktiverad i denna avstämning.
CA Uppdaterad av Codex API för 10 dagar sedan
- Kategori satt till Säkerhet och test
- Status ändrad från New till In progress
- Tilldelad satt till Codex API
- Versionsmål satt till 0.4 - Konto och historik
- % Klart ändrad från 0 till 40
- Acceptanskriterier uppdaterad (skillnader)
- Driftsättningspåverkan satt till Ingen
Arkitekturavstämning 2026-09-21: nuvarande system har inget sparat barn- eller familjeregister. Checkout skapar i stället krypterade, köp-/radspecifika deltagarsnapshots med endast artikelstyrt namn och födelseår; deltagaren är inte ett konto och kopplas inte till kortägaren som en återanvändbar profil. Rekommendation för första release: behåll denna modell. Kortägaren eller ett konto med separat kortdelning kan ange flera deltagare per tillfälle, men kortdelning ger ingen åtkomst till tidigare deltagaruppgifter. Föreningsadministratören ser snapshots endast i tenantavgränsad rapport. Kiosken verifierar inte vårdnad eller LOK-rätt. Återanvändbara barnprofiler, uttrycklig delad vårdnadsbehörighet och dess livscykel skjuts till ett separat senare ärende. Beslutet behöver användarens uttryckliga godkännande innan designunderlaget ändras och #185 kan slutföras.
CA Uppdaterad av Codex API för 10 dagar sedan
- Status ändrad från In progress till Resolved
- % Klart ändrad från 40 till 70
- Testresultat uppdaterad (skillnader)
Godkänd avgränsning dokumenterad i commit 1245b70 (pushad till codex/punch-card-types). Första release saknar återanvändbart barn-/familjeregister: namn och födelseår anges per aktuell transaktion och lagras som krypterade deltagarsnapshots. Barn behöver inget konto. Kortdelning ger saldo och nyttjande men aldrig tidigare deltagaruppgifter eller rapportåtkomst. Kiosken bedömer varken vårdnad eller LOK-stöd. Återstående kortdelning genomförs i befintliga #190-192; framtida familjeregister kräver separat scope. PlantUML-modellen är omrenderad och visuellt verifierad.