Statusloggen, der skulle have været en liste

Et flerlinjet tekstfelt, der er sat til at tilføje ændringer til den eksisterende tekst, er en nem log. Versionering slås til på listen, og hver gang nogen skriver en status, bliver den gemt i sin egen version med navn og tidspunkt. På elementet står meddelelserne under hinanden som en lille log. Sådan så opgavelisten ud: hver opgave havde et felt, der hed Status, og historikken var loggen.

I 2019 holdt det ikke længere. Loggen skulle kunne ses på tværs af opgaverne, ikke kun én opgave ad gangen, og en statusmeddelelse skulle kunne have en fil vedhæftet. Det kan en tekst i versionshistorikken ikke. Til det skal der en rigtig aktivitetsliste med ét element pr. meddelelse. Og så skulle de gamle meddelelser ud af versionerne og over i den nye liste, på flere websteder.

To trin frem for ét script#

Med få opgaver er det ligetil. Med et par tusinde opgaver og 5-10 meddelelser på hver går noget galt undervejs, og jeg vil hellere have to trin, jeg kan se ind i, end ét script, der gør det hele:

1. Udtræk med PowerShell. Et script fra SharePoint Diary, som jeg ændrede lidt, så det kunne køre på flere websteder. Det gennemgik hvert element på listen, hentede versionerne og skrev hver version med en status til en CSV-fil pr. websted: element-id, titel, statusteksten, versionsnummer, tidspunkt og hvem der skrev den. Versioner uden en status blev sprunget over. De opstod, når nogen havde ændret noget andet på opgaven.
2. Import med Fusion. CSV-filerne blev lagt ind i aktivitetslisterne på de forskellige websteder med Fusion, et værktøj, jeg havde brugt før til at flytte data. Det styrede, hvilken fil der gik til hvilket websted og hvilken liste, og gav en rapport, når jobbet var færdigt.

Delingen gav et sted at kigge mellem de to trin. CSV-filerne kunne læses og tælles, før noget blev skrevet i SharePoint, og rapporten fra importen kunne holdes op mod dem.

Scriptet, rettet så det kan køre i dag, står i Træk versionshistorikken ud af et listeelement med PowerShell.

Det, sagen mindede mig om#

Versionshistorikken er en historik, ikke en datamodel. Den er god til at se, hvem der ændrede hvad, og hvornår. Den er dårlig, så snart nogen vil filtrere, tælle eller vedhæfte noget på tværs. En log, der skal bruges til mere end at læses på elementet, skal være en liste fra begyndelsen. Det er billigere at oprette listen den første dag end at flytte tusindvis af meddelelser ud af versionerne bagefter.