Files
MijnBesluit/docs/Versiehistorie.md
T

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.