Hoi @kpompstra,

Wanneer je een lijstwaarde verwijdert, is deze niet neer beschikbaar in rapportages. Zie ook:

Hoi @Inge Kuijpers,

Dank voor je reactie en ik heb die andere artikelen gelezen. Gebruik van Kaartenbak is erg interessant maar als beginnend applicatiebeheerder moet ik dit nog ontdekken 

Wellicht is mijn verhaal niet helemaal duidelijk overgekomen en/of ben ik niet helemaal duidelijk geweest.

Ik heb even een test gedaan bij een testversie van het meldingstype voor melden incidenten.

Conclusie: Inderdaad is het zo dat als je de lijstwaarde verandert of verwijdert dat dan deze lijstwaarde niet meer beschikbaar is voor rapportages. Echter de ingevoerde data blijft wel bestaan in de database. Daar ging het mij om. We willen de optie ‘Anders, nl’ laten vervallen en een nieuwe lijstwaarde Anders toevoegen als keuzerondje, niet meer als tekstvak. Als we de historische data maar niet kwijt zijn. De historische data blijf gewoon bestaan bij het veld Soort-incident

Wat heb ik gedaan?

1. Voor het veld Soort - incident de optie ‘Anders, nl.’ aangevinkt en een nieuwe melding gemaakt. Als tekst bij ‘Anders, nl.’ ingevoerd TEST.
2. Vervolgens bij het veld Soort - incident de optie ‘Anders, nl.’ UITgevinkt en de melding opnieuw bekeken
3. De tekst TEST staat nog steeds bij de melding als data bij het veld

Zie afbeelding

Groet,

Klaas

Hoi Klaas,

Dat klopt. Bij de details van de melding is de oorspronkelijke waarde nog zichtbaar, in rapportages kun je de waarde niet meer gebruiken.

Hoi @Inge Kuijpers 

Hierbij nog even een aanvullende reactie op deze topic.

Op 30 december hebben we een nieuw meldformulier gemaakt, waarbij we nagenoeg alle bestaande velden hebben hergebruikt, maar veldwaarden hebben aangepast, verwijderd of toegevoegd.

Wat blijkt nu?

1. Als je een veldwaarde uit de lijst van een veld verwijderd, dan blijft de veldwaarde in de data bij de meldingen bestaan. Je kunt er echt niet meer op filteren/rapporteren. De enige manier om dan de oude waarden te kunnen zie is een lijstrapport maken waarbij je de optie ‘het veld is gevuld’ kiest en alle waarden ziet (oud en nieuw en verwijderde). Dit heb je ook in een ander topict gezet
2. Als je nieuwe veldwaarden toevoegt naast de bestaande veldwaarden, dan is er niets aan de hand. Alle veldwaarden kun je filteren of selecteren voor rapporten.
3. NU komt het: ik heb ook veldwaarden GEWIJZIGD. Kleine aanpassingen van tekst (tekst toevoegen, wijzigen of verwijderen) of bestaande veldwaarden volledig hernoemen.

GEVOLG: als je drie veldwaarden hebt en van alle drie wijzig je de tekst, dan wordt de nieuwe tekst getoond in filters etc. maar ook ALLE historische veldwaarden wijzigen mee!

Dit wist ik niet en dus ben ik bezig gegaan met de analyse van alle gewijzigde velden. En alleen voor wijzigingen onder nummer 3 zijn er consequenties. Dat betekent bijvoorbeeld dat ik een veldwaarde heb gewijzigd (ipv nieuwe veldwaarde) waardoor er nu ONJUISTE veldwaarden in de historie staan.

Gelukkig is dit zeer beperkt gebleven en ik ga nog in overleg met de Servicedesk of we data kunnen aanpassen :-)

Ik wilde je dit toch laten weten en zou graag een bevestiging van jullie horen of mijn bewering onder nummer 3 inderdaad klopt (eigenlijk weet ik dat al omdat ik analyses heb gedaan).

Het is wel een belangrijk item als andere organisaties ook op deze wijze veldwaarden veranderen.

Dank!

Groet,

Klaas

@kpompstra 

Je conclusie omtrent constatering 3 klopt - ik denk dat dit perspectief helpt. In feite heeft iedere lijstwaarde in een lijstveld op database niveau een uniek ID. De tenaamstelling van de lijstwaarde staat daar los van en vormt alleen een manier om de juiste keuze te maken en weer te geven.

De oplossing in deze is mijns inziens de volgende: zet alle originele tenaamstellingen terug, daarmee staat de inhoud in de oude meldingen weer goed.

Om vervolgens de nieuwe lijstwaarden in gebruik te nemen kun je deze stappen uitvoeren:

• Kopieer het betreffende veld en zet daar de nieuwe, gewenste lijstwaarden in
• Neem dat nieuwe veld in gebruik. Ik verwacht dat je daarvoor het best een kopie van je meldformulier kunt aanmaken - als je namelijk een veld van een formulierontwerp haalt, dan is de inhoud van dat veld er nog wel, maar is dat niet langer zichtbaar in de melding zelf. Doe dit ook voor eventuele workflow formulieren waar dit veld op ligt. Het is tevens belangrijk om te weten dat je geen kopie kunt maken van het coördinatorformulier
• Ga na of je je workflow voorwaarden en/of rapportage dient te wijzigen omdat je een nieuw veld gebruikt. Indien dat tot grote issues zou kunnen leiden, kopieer dan het hele meldingstype - dat garandeert dat je de nieuwe inrichting volledig los kunt halen van de historie. 

@Chaim Leunissen 

Dank voor je duidelijke reactie en ik begrijp het. Vooraf heb ik bepaalde keuzes gemaakt om de wijzigingen uit te voeren. Gedurende het vooronderzoek, het testen en vragen op community heb ik veel kennis opgedaan wat wel en niet kan. Maar nog steeds niet genoeg, daar blijf ik graag aan werken.

Ter info: we hebben alleen een productieomgeving, dus echt testen was niet mogelijk.

Idd, het coördinator formulier kan niet worden gekopieerd. Heeft meer voordelen dan nadelen denk ik.

In het kort wat ik heb gedaan:

EERST: backup gemaakt van alle bestaande meldingen met alle velden!!

Achtergrond keuzes: als je van alle meldingstypen een gezamenlijk rapport wilt maken of zaken wilt vergelijken en je gebruikt geen of weinig globale velden, dan lukt dat niet. Daar liep ik in het begin al tegen aan. Doel van mij was dus om zo weinig mogelijk nieuwe velden te maken, waar mogelijk nieuw = globaal en anders oplossing in nieuwe/gewijzigde veldwaarden. Afgeleid doel: schoon houden van velden, workflows en sjablonen. Het was een rommeltje. Leven hergebruik!

Actie 1: kopie van het meldformulier maken in het bestaande meldingstype en dat formulier aanpassen naar de nieuwe wijze, zo veel mogelijk met gebruik van bestaande velden. Echter ik kon de bestaande velden natuurlijk niet aanpassen ivm gebruik in productie. Een kopie van een veld kan, maar dan heb je een nieuw veld en nieuw veldID en dan moet je extra rapportages maken.

Actie 2: overgegaan tot het kopiëren van het volledige meldingstype en in dit nieuwe meldingstype kon ik dezelfde velden gebruiken, nieuwe toevoegen, oude verwijderen of veldwaarden aanpassen. En dit meldingstype alleen toegankelijk gemaakt voor een groep gebruikers om te testen. Hiermee verstoorde ik het productie meldingstype niet.

Actie 3: op basis van de opgedane ervaring met acties 1 en 2 en kennis het besluit genomen om toch over te gaan tot een kopie van het huidige meldingsformulier in het bestaande meldingstype. Deze kopie volledig aangepast aan de nieuwe wensen, maar nog met de oude velden en veldwaarden. In de tussentijd een draaiboek gemaakt met IST-CHANGE-SOLL voor alle velden en aan eind van het jaar (30-12-2022) heb ik het meldformulier uitgeschakeld en verborgen en het nieuwe meldformulier en velden  bijgewerkt met de nieuwe waarden.

Het coördinatorformulier bevat tijdelijk (totdat alle meldingen > 31-12-2022 zijn afgehandeld) ‘dubbele’ velden in sommige gevallen (oude en nieuwe velden), zodat je het coördinatorformulier voor beide meldformulier kan gebruiken. Idem voor het analyseformulier.

Uiteraard heb ik ook alle publieke filters, rapportages, workflow e.d. geanalyseerd en waar nodig aanpassingen gedaan voor oude/nieuwe velden. Dit viel reuze mee!

De positieve kanten van dit traject:

• Veldwaarden in de historie wijzigen mee waar je dat ook zou willen
• Geen tweede meldingstype nodig, geen dubbele velden
• Beperkte aanpassing van rapportages en publieke filters
• Oude veldwaarden blijven bewaard (eruit te halen met lijstrapportage zoals in vorige bericht genoemd)
• Vereenvoudiging van het meldformulier kunnen realiseren
• Workflow hoefde niet te worden aangepast, behalve het actieoverzicht  (e-mailproces e.d. op met voorwaarden op basis van nieuwe veldwaarden) bij de statusovergang van Concept → In behandeling

De leermomenten:

• Veldwaarden kun je wijzigen, maar beter is het om eerst te kijken waar je de oude veldwaarde kunt wijzigen in een vergelijkbare nieuwe en anders de oude waarde(n) volledig te verwijderen en nieuwe toe te voegen (de oude blijven immers dan gewoon in de database staan!)
• Nu een analyse afronden waarbij ik de echte issues naar boven haal (nu nog maar 1) en die oplos door wijzigingen in de database. De criteria voor wijziging van data kan ik samenstellen
• Tja, als je begint maak je keuzes, de keuzes die in het verleden zijn gemaakt bij het in gebruik nemen van Zenya waren bepalend voor de oplossing die nu is gekozen.
• Nieuwbouw is makkelijker dan verbouw :-)

Al met al ben ik wel blij met de manier waarop ik het nu heb gedaan. Alleen had ik het moeten weten van deze veldwaarden, dan was het helemaal goed geweest.

Dank!