Explorar el Código

P1-42 blijkt af; twee views uit elkaar gehouden

De view-export van flutterflowmobiel1 toont datumsortering (oplopend) plus
een filter >= -2 hours, en de displays erven die sortering. Live nagemeten
op services_1/3/5: alles begint op de dag van meten en loopt oplopend
door. P1-42 stond nog als "meest zichtbare probleem" genoteerd.

Wel een nieuw signaal: services_4, _6 en _7 geven landelijk 0 items, _3
geeft er 1 - drie Home-tabs zijn daarmee leeg.

CLAUDE.md: flutterflowmobiel1 (Home, pager 25) en
flutterflowmobiel_establishments (horeca, pager 100) zijn verschillende
views; en een Drupal-pager is iets anders dan FlutterFlow's Max Items.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
bob hace 5 días
padre
commit
1d1bef8c35
Se han modificado 2 ficheros con 45 adiciones y 8 borrados
  1. 21 0
      CLAUDE.md
  2. 24 8
      TASKS.md

+ 21 - 0
CLAUDE.md

@@ -1903,6 +1903,27 @@ jouw laatste export nog de actuele staat weergeeft — draai er een
 verse. Bevestigd 2026-09-02, toen Bob en Claude onafhankelijk hetzelfde
 component omzetten.
 
+**Twee views die op elkaar lijken maar niets met elkaar te maken hebben —
+haal ze niet door elkaar.** Bevestigd 2026-09-09:
+- **`flutterflowmobiel1`** voedt de **Home-tabs** (contenttypes `activity`
+  en `go_out_event`), displays `services_1` t/m `services_7`. Pager:
+  **25 per pagina**. Master sorteert op `field_date_value` oplopend en
+  filtert `>= -2 hours`; de displays erven dat (ze zetten
+  `defaults['sorts']` niet uit).
+- **`flutterflowmobiel_establishments`** voedt het **horeca-overzicht**
+  (`HorecagelegenhedenOverzicht(Copy3)`). Pager: **100 per pagina**.
+  Sorteert op nid aflopend.
+
+Ze hebben dus een **verschillende pagergrootte**, en een `items_per_page`
+die je in de ene view-export ziet zegt niets over de andere. Meet het
+gewoon: vraag `page=0,1,2…` op en tel tot een pagina minder dan de
+paginagrootte teruggeeft.
+**Verwar een Drupal-pager verder niet met FlutterFlow's `Max Items`** —
+dat laatste is een veld in het *Generate Dynamic Children*-paneel dat in de
+export een `.take(N)` oplevert, volledig los van Drupal. Zie je in de app
+precies N items terwijl de API er meer teruggeeft, kijk dan daar en niet in
+de view.
+
 **Een taxonomie-/categorie-id verifiëren zonder het te gokken: test het
 endpoint rechtstreeks.** Bevestigd nuttig 2026-09-02 (een `horcat` was
 naar een niet-bestaande categorie gezet; de tab bleef leeg zonder

+ 24 - 8
TASKS.md

@@ -17,12 +17,25 @@ geen enkele `has no instance method`-fout in de run-log. **Bijvangst:
 
 Wat er nog ligt, allemaal in dezelfde views:
 
-- **P1-42** — alle zeven displays sorteren op `created DESC` i.p.v. op
-  eventdatum, waardoor 90-100% van wat de lijsten tonen al geweest is.
-  Filter `datum >= vandaag` + oplopend sorteren. Volledige audit als
-  tabel bij de taak. **Dit is nu het meest zichtbare probleem in de app:**
-  door P1-44 tonen Activiteiten, Films en Jeugd hun eigen lijst, en die
-  staat vrijwel volledig in het verleden.
+- ~~**P1-42** — alle zeven displays sorteren op `created DESC`.~~
+  **BLIJKT AF (geverifieerd 2026-09-09 op productie).** De view-export van
+  `flutterflowmobiel1` toont in de Master een sortering op
+  `field_date_value` (oplopend, geen DESC) én een filter
+  `field_date_value >= -2 hours`; de displays zetten `defaults['sorts']`
+  niet uit, dus ze erven die sortering allemaal. Live nagemeten op
+  services_1/3/5: alle items beginnen op de dag van meten en lopen
+  oplopend door, geen enkel item in het verleden. **Wel een nieuw signaal,
+  zie hieronder.**
+- **⚠️ NIEUW (2026-09-09) — drie Home-tabs zijn nu leeg.** Landelijk
+  gemeten (geen `townid`), pagina 0: services_1 (homeslider) 7 items,
+  services_5 (cultuurinfo) 6, services_3 (uitgaan) **1**, en
+  services_4 (stadsactiviteiten), services_6 (films) en services_7 (jeugd)
+  **0**. Dat is het spiegelbeeld van het oude probleem: met het
+  datumfilter erin blijft er bijna niets over. Vraag voor Bob: klopt dit
+  met de hoeveelheid toekomstige content die er echt is, of staat er een
+  categoriefilter te streng (services_6 filtert op één tid `36074`,
+  services_4 op `18004`)? Een tab die structureel leeg is, is voor een
+  gebruiker niet te onderscheiden van een kapotte tab.
 **P1-46 · Eigenaar: Bob — er staat vrijwel geen toekomstige content in
 het systeem, en dat is nu zichtbaar.** Gevonden 2026-09-09 direct na de
 P1-42-deploy. Complete tellingen op productie: 1 toekomstig Uitgaan-event
@@ -40,8 +53,11 @@ lijst** — een technisch perfecte app zonder programma is leeg.
   max 10 items. In een steekproef van 15 zaken toonden er 4 uitsluitend
   verlopen evenementen. Zelfde ingreep als P1-42.
 - **Horeca-overzicht sorteren** — `flutterflowmobiel_establishments`
-  sorteert op nid aflopend (nieuwste inschrijving eerst). Voorstel:
-  alfabetisch op naam; sluit aan op het zoekveld uit P2-6.
+  sorteert op nid aflopend (nieuwste inschrijving eerst). **Herbevestigd
+  2026-09-09:** Amsterdam/Eetgelegenheden geeft nid 91145, 75670, 75547 —
+  dus nog steeds aflopend op nid. Voorstel: alfabetisch op naam; sluit aan
+  op het zoekveld uit P2-6. Let op: dit is een **andere view** dan
+  `flutterflowmobiel1`, met een eigen pager van **100** per pagina.
 - **P2-1** — datumfilter (Vandaag / Dit weekend / Deze week). Vergt een
   exposed date-filter; pas zinvol ná P1-42.
 - **P1-5** — "Thuis bezorgen". De data bestaat al (`afhaalopties` bevat