Files
MijnBesluit/docs/Versiehistorie.md
T

3.4 KiB

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.