Functionele release notes GIPOD 4.3

Transcriptie

1 Functinele release ntes GIPOD 4.3 Nieuwe functinaliteiten Nieuwe alarmlijsten Er zijn 2 nieuwe alarmlijsten beschikbaar: "Mijn WO: hinder niet vldende ingevuld" & "Mijn MAN: hinder niet vldende ingevuld". Zie 'Gewijzigde functinaliteiten: Hinder stapsgewijs meer ingeven' vr meer inf. Vr WO wrdt enkel een alarm gegenereerd indien de hinder nvldende ingevuld is bij cncreet geplande werkpdrachten en werkpdrachten in uitvering. Niet-cncreet geplande en uitgeverde werkpdrachten krijgen dus nit een alarm van dit type. Vr MAN wrdt enkel een alarm gegenereerd indien de hinder nvldende ingevuld is bij vergunde manifestaties en manifestaties waarvan de status nbekend is (vergangsmaatregel tt eind 2016). Vr MAN die vlledig in het verleden liggen, zal het alarm verwijderd wrden. Er is geen migratiescript uitgeverd vr bestaande innames. Deze zullen pas bij een nieuwe statuswijziging in alarm kmen, als de hinder nvldende ingevuld is. Histriek van de planning van een werkpdracht Als raadpleger f bijdrager kan je nu alle wijzigingen aan de peride f status van een werkpdracht bekijken via de knp Histriek (van de planning) p het tabblad Algemeen van de werkpdracht. Gewijzigde functinaliteiten Cncreet geplande WO wrden altijd ntslten Werkpdrachten met de status 'cncreet gepland' wrden vanaf nu altijd ntslten via de GIPOD public API, net als werkpdrachten met de status 'in uitvering'. Werkpdrachten met de status 'niet-cncreet gepland' en 'uitgeverd' wrden niet ntslten. Dit werd beslist in de business werkgrep van 23/10/2015, m ervr te zrgen dat data beter en sneller ntslten wrdt. Vrheen werd een cncreet geplande WO enkel ntslten als er een effectieve peride was, én als de publicatiedatum gepasseerd was. Beide vrwaarden vervallen. We ntsluiten gewn de peride van de cncreet geplande werkpdracht, gezien er geen nderscheid meer is tussen geplande en effectieve peride (zie nder) en de publicatiedatum niet langer bestaat (zie nder). 'Publicatiedatum' bestaat niet langer In de business werkgrep van 23/10/2015 is beslten dat cncreet geplande werkpdrachten altijd ntslten mgen wrden (zie bven). Hierdr is de functinaliteit 'publicatiedatum' niet langer ndig. Deze is geëlimineerd uit GIPOD, zwel bij de details van een werkpdracht, bij de delegatierechten als bij de instellingen van een rganisatie.

2 Herwerking peride van een werkpdracht De peride van een werkpdracht zal niet langer uit 2 verschillende perides (geplande en effectieve peride) bestaan. Dit creëerde enkel verwarring vr de gebruikers en hergebruikers van de data. Ok werden er veelal fute perides ingegeven, mdat men geen exacte data ter beschikking had bij het ingeven van niet-cncreet geplande werkpdrachten, maar deze wel vrzien mesten wrden. De peride van een niet-cncreet geplande werkpdracht wrdt vanaf deze release gedefinieerd dr een tijdsvenster en een geschatte duur: Tijdsvenster = peride waarin de werkpdracht zal plaatsvinden; bepaald dr 2 data (van tt ) Geschatte duur = geschatte drlptijd van de werkpdracht; bepaald dr aantal kalenderdagen (met altijd kleiner f gelijk aan de duur van het tijdsvenster zijn) De peride van werkpdrachten met status cncreet geplande, in uitvering f uitgeverd wrdt vanaf deze release gedefinieerd dr een starttijdstip, een eindtijdstip en de effectieve duur: Starttijdstip = mment waarp de werken starten; bepaald dr een datum + tijdstip Eindtijdstip = mment waarp de werken afgelpen zijn; bepaald dr een datum + tijdstip OF berekend adhv de duur Duur = effectieve duur van de werken; wrdt ingegeven samen met starttijdstip OF berekend adhv start- en eindtijdstip Geplande peride, effectieve peride en marges verdwijnen dus (na een vergangsperide, vrzien tem eind 2017). De ude services die ng gebruik maken van deze geplande & effectieve peride (en evt. marges), zullen dus ng een jaar ndersteund wrden. De geschatte duur is vrlpig een vrijblijvend veld, en zal k na deze vergangsperide verplicht wrden via de services. In de webapplicatie is dit veld verplicht in te vullen. Cnflictdetectie vr een niet-cncreet geplande werkpdracht gebeurt in het vlledige tijdsvenster. Mgelijke cnflicten kunnen input leveren vr de uiteindelijke cncrete planning van een werkpdracht. Vr werkpdrachten met status cncreet gepland en in uitvering gebeurt cnflictdetectie tussen starttijdstip en eindtijdstip van de werkpdracht. Hinder: bekend/nbekend + stapsgewijs meer ingeven Bij het aanmaken van een werkpdracht f manifestatie zal men nmiddellijk meten aangeven f de hinder bekend f nbekend is. Indien men 'bekend' aanduidt, zal men minstens 1 lcatie van hinder meten selecteren. Alle bestaande innames waarbij er geen hinder ingegeven is, zullen mgezet wrden naar "hinder nbekend". Men kan later de hinder ng altijd aanvullen, indien hierver meer geweten is. Om sneller, meer en crrectere infrmatie ver de hinder in GIPOD te krijgen, zal het niveau van ingeven gekppeld wrden aan de status van de inname. Z kunnen we er k vr zrgen dat er betere hinder infrmatie ntslten kan wrden via de public API. WO niet-cncreet gepland: hinder nbekend / bekend (waarbij dan minstens 1 lcatie aangeduid wrdt) --> nit een alarm WO cncreet gepland: hinder bekend met minstens 1 lcatie aangeduid WO in uitvering: hinder bekend met lcatie(s) en gevlg(en) aangeduid WO uitgeverd: hinder bekend met lcatie(s) en gevlg(en) aangeduid --> nit een alarm

3 MAN niet-vergund: hinder nbekend / bekend (waarbij dan minstens 1 lcatie aangeduid wrdt) -- > nit een alarm MAN vergund: hinder bekend met lcatie(s) en gevlg(en) aangeduid MAN nbekend (vergangsmaatregel): hinder bekend met lcatie(s) en gevlg(en) aangeduid Indien de hinder nvldende gespecifieerd is vlgens deze business regels, zal er een alarm gegenereerd wrden vr de beheerder van de inname en de evt. gedelegeerden van de inname (indien het delegatierecht 'hinder' werd tegekend). Z wrden de beheerder en gedelegeerden er attent pgemaakt dat de hinder verder aangevuld met wrden, znder te verhinderen dat ze een statuswijziging kunnen drveren. Er zal k een waarschuwingsbdschap meegegeven/getnd wrden wanneer men het detail van de inname pvraagt. Deze aanpassing is beslist tijdens de business werkgrep van 23/10/2015. Deze is ng niet geldig p bestaande innames, daarvr zijn er geen alarmen berekend. Bij een vlgende statuswijziging zal dit wel het geval zijn, als de hinder nvldende ingevuld is. Delegatierechten werkpdracht: "status" en "peride" => "status & peride" De delegatierechten "status" en "peride" wrden samengevegd tt 1 delegatierecht "status & peride" vr werkpdrachten. Bij het aanpassen van de status van een werkpdracht, met men sms k andere datumvelden invullen. Dit zu prblemen pleveren als we deze delegatierechten niet samenvegen. Bij bestaande delegaties waar slechts 1 van beide delegatierechten werd tegekend (status OF peride), zal dit autmatisch mgezet wrden naar het delegatierecht "status & peride". Ter inf: bij manifestaties blijven dit 2 aparte delegatierechten. De status is daar "vergund" f "nietvergund" en is veel minder direct verbnden met de peride van de manifestatie, dan dat dat bij werkpdrachten het geval is. Cnflictberdeling: Ja / Nee / Niet Berdeeld De berdeling van een cnflict zal vanaf nu slechts 3 waarden kunnen aannemen: Ja, Nee f Niet Berdeeld. De ptie "Geen mening" vervalt dus. Dit zrgde enkel vr verwarring: het was niet duidelijk f men het cnflict ng niet berdeeld had, f als rdeel "geen mening" had gegeven. Een nieuw gegenereerd cnflict zal dus standaard de berdeling "Niet Berdeeld" meekrijgen. Men kan dan, na het bekijken van het cnflict, dit berdelen met "Ja" (= het is een geldig cnflict) f "Nee" (= het is geen geldig cnflict; maw er zal in de praktijk geen prbleem zijn wat de hinder betreft). Ok heeft men de mgelijkheid m zijn berdeling te wissen, het cnflict gaat dan terug pnieuw naar "Niet Berdeeld". Cnflicten pzeken die pnieuw berdeeld meten wrden Men kan cnflicten pzeken p basis van de berdeling (ja/nee/niet berdeeld), maar k wanneer een cnflict herberdeeld met wrden. Wanneer men een cnflict berdeeld heeft, maar achteraf wrdt er iets gewijzigd aan 1 van beide cnflicterende aanwezigheden zdat het cnflict herberekend is, zal dit cnflict gemarkeerd wrden in de webapplicatie met een uitrepingsteken in een gele bl. Dit wil zeggen dat men het cnflict pnieuw met berdelen.

4 Deze cnflicten kan men vanaf nu pzeken via de zekpdracht "Zeken Cnflicten" met zekcriterium "Mijn Berdeling = Te Herberdelen". Hiermee zal men alle cnflicten te zien krijgen die ng gewijzigd zijn na een eerdere berdeling. In de excel-exprt van deze zekresultaten zal de markering "te herberdelen" weergeven wrden dr een asterisk. Dergelijke cnflicten zijn dus te zien met de berdeling "Ja*" f "Nee*" in plaats van het uitrepteken in de gele bl. Cnflicten met niet-cncreet geplande WO zijn nit ernstig Een cnflict met een niet-cncreet geplande WO, zal nit als "ernstig" bestempeld wrden. Ok al vldet het vr het verige aan de criteria vr een ernstig cnflict: verlap van de eigenlijke zne (niet enkel in de ruimtelijke buffer) & verlap van de peride (niet enkel in de tijdsbuffer = marges). Met de nieuwe invulling van de peride van een WO, is bepaald dat vr niet-cncreet geplande WO cnflicten gedetecteerd wrden in het tijdsvenster van de WO (vreger was dit in de geplande peride + marges). Hierdr zullen smmige cnflicten die vreger in de marges vielen, nu in het tijdsvenster vallen en als ernstig bestempeld wrden. Om dit te vermijden, en mdat het tijdsvenster een inschatting is, zullen deze cnflicten vr niet-cncreet geplande WO per definitie als "niet-ernstig" bestempeld wrden. WO niet verwijderen wanneer dit enige WO van pilt in SYN is Als beheerder zal je een WO niet langer kunnen verwijderen, wanneer deze WO de enige actieve WO van de pilt in een SYN is. Anders zu deze SYN achterblijven znder actieve werkpdracht van de pilt erin. De pilt kan mmenteel zijn enige actieve WO niet verwijderen uit de SYN, maar de WO zelf verwijderen kan wel. Er wrdt dan een waarschuwingsbdschap getnd. Vanaf deze release zal dit niet langer mgelijk zijn, en zal je een futbdschap te zien krijgen met de reden waarm je deze werkpdracht niet kan verwijderen. Aanpassing business regels vr 2 alarmlijsten De business regels vr alarmlijsten "Mijn WO: afwijking met synergie" en "Mijn SYN: afwijkende WO" zijn aangepast. Wanneer de werkpdracht en/f de synergie status "uitgeverd" heeft, zal er geen alarm meer berekend wrden en zullen bestaande alarmen autmatisch verwijderd wrden. Het kan immers niet de bedeling zijn dat men retr-actief alarmen met plssen vr reeds uitgeverde werkpdrachten f synergieën. (Sub)rganisatie tnen in mail In de dagelijkse f wekelijkse mail met penstaande alarmen en nieuwe infberichten wrdt vrtaan vermeld vr welke rganisatie (f subrganisatie) je deze mail ntvangt.

5 Opgelste bugs Tevegen van een werkpdracht aan een synergie lukt niet in IE bij beamer reslutie mdat de knp "tevegen" niet aanklikbaar is in het verkleinde scherm. Smmige warnings blijven p scherm getnd wrden, terwijl ze niet meer van tepassing zijn. Wanneer je interesse tnt in een WO van de eigen rganisatie, ntvang je de SA niet wanneer deze gelanceerd wrdt. Hierdr kan je zelf niet antwrden p de SA en geen 2e WO kppelen indien gewenst. Smmige wijzigingen (bijv. gewijzigde peride) wrden nterecht 2x getnd in het tabblad Wijzigingen van een werkpdracht. Cnflicten tussen 2 aanwezigheden wrden sms dubbel gecreëerd. Zeken Aanwezigheden geeft sms een time ut wanneer de zekcriteria heel ruim zijn (Beheerder = Alle; Lcatie = Vlaanderen; Inname = werkpdrachten & manifestaties). Icntjes vr werkpdrachten in synergie f in synergie-aanvraag krijgen niet veral de juiste kleur (in synergie-aanvraag = ranje; in synergie = gren). Tijdstip Laatste Wijziging wrdt sms nterecht aangepast, sms wrdt dan weer het vrige tijdstip getnd. Zeken Synergieën tnt enkel synergieën waar de rganisatie uit de zekcriteria pilt is, en niet de synergieën waar een werkpdracht van de rganisatie in zit. Deze zuden wel getnd meten wrden. Bij Zeken Cnflicterende Aanwezigheden met als type "Bus-Tram-Metr" wrdt geen rekening gehuden met de meegegeven referentie f beschrijving in de zekcriteria. Bij Zeken naar Innames met Hinder wrden bij het gebruik van zekcriterium "Status = Onbekend" tch manifestaties met andere statussen getnd. Links naar alarmen en infberichten in ntificati linken niet altijd dr naar de juiste lijst. De exprt van de zekresultaten vr Zeken Synergie-aanvragen met als criterium "Status = Alle" blijft laden, de excel wrdt niet getnd. Het is mgelijk m via webservices 2x dezelfde werkpdracht te te vegen aan een synergie-aanvraag. Bij het melden van een GRB-afwijking krijgt men sms de bdschap "Er is technisch iets verkeerd. Prbeer later pnieuw." Een verwijderde manifestatie kan ng bewerkt wrden (na het verwijderen dus). Technische verbeteringen De synchrnisatie tussen de GIPOD databank en de public API lpt cntinu, ipv 4x per dag (6u-12u-18u- 24u). Gegevens die aangemaakt wrden in GIPOD en vlden aan de publicatieregels, zullen dus quasi nmiddellijk (na verwerking ervan) pvraagbaar zijn via de public API en dus k zichtbaar zijn in de Hinder In Kaart-applicatie p gepunt.be en via de GIPOD public WMS. De vlledige GIPOD-tepassing (SOAP services, webapplicatie, public API) werd gemigreerd naar de Clud (Azure).