diff --git a/FEATURE_BACKLOG.md b/FEATURE_BACKLOG.md index 759338e..bc0c972 100644 --- a/FEATURE_BACKLOG.md +++ b/FEATURE_BACKLOG.md @@ -7,8 +7,8 @@ > Status-koder: ✅ ferdig · 🔨 pågår · 📋 planlagt/fanget · ❓ trenger beslutning > · 🔀 endret fra opprinnelig råd · 💤 utsatt (bevisst) > -> Sist oppdatert: 2026-08-17 (NGF-spilleform-sammenligning, manuell -> koordinat-editor og spiller-CSV-import notert, se seksjonene nederst) +> Sist oppdatert: 2026-08-20 (funksjonelle hull funnet under design- +> dokumentasjon-runden notert, se seksjonen nederst) --- @@ -4678,3 +4678,101 @@ verifisering, samme inkrementelle disiplin som resten av appen): selv blir locale-bevisst (bryter det bevisste "ingen backend- endring for oversettelse"-valget i ADR-094). Feilmeldinger forblir norsk uansett språkvalg inntil en av disse løsningene velges. + +## Funksjonelle hull funnet under "design-dokumentasjon"-runden (2026-08-20) — 📋 ikke fikset, kun notert + +**Kontekst:** bruker ba om en fullstendig funksjonell spesifikasjon av +ALLE skjermer i appen (dashbord + 13 områdedokumenter, publisert som +artefakter), til bruk som grunnlag for en designer. Målet var å +beskrive hva som FINNES, ikke å lete etter feil -- men research- +prosessen (full gjennomlesning av all frontend-kode, i noen tilfeller +også backend-autorisasjon) avdekket en del reelle, eksisterende +funksjonelle hull underveis. Disse er IKKE fikset -- kun fanget opp og +notert her, som egne, fremtidige, avgrensede runder. Hvert punkt +under er hentet direkte fra research denne runden, ikke gjettet. + +- **Rundelisten (`/my-rounds`, `/my-rounds/course/[name]`):** + mislykkes selve hentingen, kan en feilmelding og en tilsynelatende + EVIGVARENDE "Laster runder…"-indikasjon vises SAMTIDIG -- ingen + tydelig avsluttet feiltilstand for brukeren å reagere på. +- **Varsler (`/my-notifications`):** "ingen varsler" og "henting av + varsler feilet" vises i dag med nøyaktig samme tomme tilstand -- + brukeren kan ikke skille reell tomhet fra en faktisk feil. +- **Ny-runde-veiviseren, steg 2 (Spilleform):** minimums-spillerantall + for Skins ("minst 3") og Københavner ("nøyaktig 3") vises kun som + hjelpetekst -- IKKE håndhevet. Veiviseren lar brukeren fullføre og + opprette runden uansett faktisk spillerantall. +- **Ny-runde-veiviseren, steg 4 (Lag og rekkefølge):** minimum 2 + spillere i "Laget" for scramble mot enkeltspiller er kun en + informativ statusindikator -- ingen faktisk sperre på å gå videre. +- **Ny-runde-veiviseren, steg 5 (Deling):** advarselen om at "0 + vennekategorier valgt" betyr at ingen venner faktisk kan se runden, + hindrer IKKE innsending -- kun informativ. +- **Turnering (individuell), Scorekort-fanen -- rettighetsbegrensning + usynlig i UI:** backend (`app/routers/individual_tournaments.py`, + `app/team_authz.py`) begrenser hvem som kan REGISTRERE/ENDRE en + deltakers score/GPS-flagg til (a) deltakeren selv, eller (b) + org-eier/administrator -- et vanlig org-medlem kan altså IKKE + registrere for andre. Dette vises INGEN steder i grensesnittet før + et lagringsforsøk faktisk feiler med en generisk feilmelding. +- **Samme fane -- DSQ/RTD/DNF/DNS-status og Cut:** begge blokkerer ny + score-registrering (for hele turneringen, hhv. for runder etter + cut-grensen), men INGEN av delene vises i selve Scorekort-fanen -- + oppdages kun ved mislykket lagringsforsøk. +- **Samme fane -- Bingo Bango Bongo-panelet:** lagringsfeil er i dag + HELT stille -- ingen tilbakemelding overhodet ved mislykket lagring, + til forskjell fra absolutt alle andre lagringsflyter på samme fane. +- **Samme fane -- fjern flaggplantning:** mislykkes selve fjerningen, + får brukeren i dag INGEN tilbakemelding -- grensesnittet antar + alltid at det gikk bra. +- **Samme fane -- brutto/netto-inkonsistens i score-cellen:** hvilken + av de fem resultatkategoriene (eagle/birdie/par/bogey/dobbel bogey+) + en celle havner i regnes ut fra NETTO resultat, men TALLET som + faktisk vises i cellen er alltid BRUTTO -- kan fremstå + selvmotsigende for en spiller med tildelte slag på hullet. +- **Samme fane -- flaggkart-synlighet:** ingen eier/administrator- + unntak når kartoversikten over flagg IKKE er satt offentlig av + organisator -- selv org-eier/administrator ser da kun sine EGNE + plantede flagg, ulikt selve score-/flagg-REGISTRERINGEN (der + eier/administrator har en eksplisitt unntaksrett, se punktet over). +- **Organisasjon -- rolletilpasning ujevn:** kun Medlemmer-siden + henter og håndhever brukerens rolle (Eier/Administrator/Medlem) i + grensesnittet. Spillerpool- og Order of Merit-sidene viser samme + fulle rediger/opprett/slett-handlingssett til ETHVERT + organisasjonsmedlem, uansett rolle -- uklart fra frontend-koden + alene om noe håndheves usynlig server-side. Bør avklares eksplisitt + (enten bevisst full tilgang for alle medlemmer, eller server-side + rollesjekk legges til) fremfor å forbli en tilfeldighet. +- **Organisasjon -- bekreftelse ujevnt fordelt:** fjern medlem/forlat + organisasjon og slett hele Order of Merit-serien krever eksplisitt + bekreftelse; fjern lenket turnering (fra en Order of Merit-serie), + slett Order of Merit-lag, fjern lagmedlem og opphev invitasjon gjør + det IKKE, til tross for at flere av disse også er vanskelige/umulige + å angre. +- **Organisasjon -- Order of Merit "Eclectic"-regelen skjult:** + kravet om at ALLE lenkede turneringer må spilles på samme bane for + at Eclectic-aggregering skal fungere, vises kun i en LUKKET, ikke- + utvidet innstillings-seksjon -- en organisator oppdager regelen + først når et lenkeforsøk blir avvist av serveren. +- **Turnering (individuell), Oppsett -- bekreftelse ujevnt fordelt:** + fjern deltaker og fjern klasse krever ingen bekreftelse i det hele + tatt; slett runde bruker en to-stegs inline-bekreftelse; slett + turnering og anvend cut bruker fullverdige advarselsdialoger -- + ingen tydelig, gradert logikk bak forskjellen i dag. +- **Samme sted -- fjern klasse, stille konsekvens:** deltakere satt + til en klasse som fjernes mister klassetilhørigheten sin stille, + uten noen egen advarsel om akkurat DEN konsekvensen (selve + klasse-fjerningen har uansett ingen bekreftelse i det hele tatt, se + punktet over). + +**Fullstendig kontekst for hvert punkt** (nøyaktig hvor i koden, og +nøyaktig hvilke andre regler det henger sammen med) finnes i de +respektive funksjonsspesifikasjons-dokumentene sine "Oppsummert: +hva vi ber designeren om"-seksjoner (Egne runder del 1, Sosialt, +Turnering individuell del 2, Organisasjon-administrasjon) -- +publisert som Claude-artefakter denne runden, ikke egne filer i +repoet. **Neste steg:** triasjere denne listen i egne, avgrensede +runder (sannsynligvis flere -- de spenner fra rene UX-forbedringer +til det som kan være en reell autorisasjons-/synlighets-beslutning +verdt en ADR, se rolletilpasning-punktet) -- ikke noe som bør fikses +alle på én gang.