Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_014MGLqt1uKfNARQHut9ifcx
59 lines
3.4 KiB
Markdown
59 lines
3.4 KiB
Markdown
# Versiehistorie
|
|
|
|
De lijst "wat is er nieuw" die onder **Versiehistorie** staat, op de website (pop-up vanaf het
|
|
overzicht) en in de app (onderaan het startscherm), staat in de database. Een nieuwe regel vraagt
|
|
daarom **geen nieuwe versie van de app** in de Play Store of App Store, en je houdt het op één
|
|
plek bij.
|
|
|
|
## Hoe het werkt
|
|
|
|
* Tabel `version_history`: één rij per regel, met `datum`, `versie` (mag leeg), `kop` (het vette
|
|
kopje), `tekst`, `zichtbaar`. Gewone tekst, geen opmaak. Dezelfde kop op dezelfde dag kan maar
|
|
één keer voorkomen.
|
|
* De website leest de tabel rechtstreeks (`VersiehistorieService.ZichtbaarAsync`). De app vraagt
|
|
hem op bij de server met de actie `app.versiehistorie` (zie `Socketprotocol.md`) en toont een
|
|
melding als dat niet lukt.
|
|
* Volgorde: nieuwste dag bovenaan, binnen één dag in de volgorde van invoer. Opeenvolgende regels
|
|
met dezelfde dag en versie komen onder één kop te staan ("20 oktober 2026 · versie 1.1").
|
|
* Beheren doet een beheerder op de website: **Beheer > Versiehistorie beheren**. Toevoegen,
|
|
wijzigen, verbergen en verwijderen; elke wijziging komt in het auditlogboek
|
|
(`VersiehistorieBeheerd`). Een verborgen regel zien lezers niet meer, maar is niet kwijt.
|
|
|
|
## Wat erin hoort
|
|
|
|
Nieuwe of wezenlijk gewijzigde functies: "wat kan ik nu wat ik eerst niet kon". Geen bugfixes,
|
|
geen tekstuele correcties, geen opmaak die is rechtgezet.
|
|
|
|
## Uitrollen
|
|
|
|
1. `db\22_versiehistorie.sql` via de databasescripts van SideKick (maakt de tabel; verandert niets
|
|
aan bestaande gegevens en is opnieuw te draaien).
|
|
2. Als root: `mysql -u root -p < db\02_applicatiegebruiker.sql` (rechten voor `mijnbesluit_app`
|
|
op de nieuwe tabel) en `mysql -u root -p mijnbesluit < db\handmatig\22b_versiehistorie_startrijen.sql`
|
|
(de bestaande regels; `INSERT IGNORE`, dus opnieuw draaien is veilig).
|
|
3. Voor de changelog in SideKick (optioneel, kan ook later): als root
|
|
`mysql -u root -p mijnbesluit < db\handmatig\22c_serverchangelog_view.sql` (zie hieronder).
|
|
4. Daarna pas de website en de SocketServer uitrollen. Andersom leest de nieuwe code een tabel
|
|
die er nog niet is, of waar de applicatiegebruiker nog niet bij mag.
|
|
|
|
## Changelog in SideKick
|
|
|
|
Het tabblad Changelog van SideKick leest een tabel of view `serverchangelog` met vaste kolommen. De
|
|
versiehistorie is de changelog van MijnBesluit, dus er is geen tweede lijst: de view
|
|
`serverchangelog` (script `db\handmatig\22c_serverchangelog_view.sql`, als root) geeft
|
|
`version_history` in dat formaat terug. `Product` is vast "MijnBesluit", `Soort` vast "Nieuw" (de
|
|
lijst bevat geen bugfixes), `Actief` is `zichtbaar` en `Updatedatum` is `gewijzigd_op`, dat de site
|
|
bij elke wijziging opnieuw zet. De agent leest de view alleen.
|
|
|
|
Instellen in SideKick bij de agent van MijnBesluit: "Changelog: tabel" = `serverchangelog`, `DbNaam` =
|
|
`mijnbesluit`, en een gebruiker met SELECT op de view (het script geeft dat aan `mijnbesluit_app`;
|
|
een aparte leesgebruiker kan ook, het voorbeeld staat in het script). Het wachtwoord alleen op de
|
|
server invullen. Voorwaarden: de agent kent de actie `ChangelogLezen` en het project staat op Weg hub.
|
|
De inhoud gaat naar het SideKick-scherm van de beheerder: geen persoonsgegevens in een regel.
|
|
|
|
## Oudere apps
|
|
|
|
De tekst van de versiehistorie zat tot en met appversie 1.1 (versiecode 3) in de app zelf. Die
|
|
apps lezen de tabel nooit en tonen dus hun ingebakken tekst, ook als je hier iets bijzet. Vanaf
|
|
versiecode 4 haalt de app de lijst op bij de server.
|