KENSAI Productupdate: rapporten hebben een echte lijst nodig, niet alleen ondertekende URL’s

Een ondertekende URL kan een PDF leveren, maar geen productgeheugen vervangen. De nieuwe K1B-regel is simpel: gegenereerde rapporten horen in een zichtbare, blijvende lijst waar operators op kunnen vertrouwen.

Waarom dit een productregel werd

Een eenmalige ondertekende URL is aflevering, geen productstructuur. Operators moeten kunnen zien wat er is gegenereerd, wanneer dat gebeurde, of het nog beschikbaar is en hoe het opnieuw te openen is zonder in chats of browsergeschiedenis te graven.

Wat vandaag is geverifieerd

Het nuttige deel bestaat al in de backend. K1B slaat rapportregels op en biedt GET /api/k1b/reports met een optionele company_id-filter. De respons bevat al de velden die een serieuze rapportenlaag nodig heeft: pdf_url, generated_at, expires_at, download_count, status en file_size_bytes.

Wat nog ontbreekt aan het productoppervlak

De beslissing van vandaag was hard: alleen ondertekende links zijn niet genoeg. Er ontbreekt een eersteklas rapportenpagina of -tabel die gegenereerde PDF’s newest-first toont met duidelijke open- en downloadacties. Zonder die pagina heeft de backend geheugen, maar voelt het product nog vergeetachtig aan.

Waarom dit operationeel telt

Securitywerk produceert bewijs, en bewijs verliest waarde wanneer het lastig terug te vinden is. Een blijvende rapportlijst maakt van elke gegenereerde PDF een verantwoord artefact in plaats van een wegwerplink. Dat helpt audits, overdrachten, klantopvolging en het vertrouwen van operators.

Kort gezegd

K1B komt dichter bij een betrouwbaar rapportproduct omdat de regel nu expliciet is: de canonieke ervaring is een zichtbare rapportlijst, geen losse verzameling vervallende URL’s. Zo stopt productgeheugen met lekken.