Innhold i v1.36-release av FtB tilegnet nabovarsel

Vi har før sommeren, i løpet av august og inn i september jobbet med å få på plass vesentlige forbedringer og feilrettinger som berører nabovarslingstjenesten; nabovarsel, varslingsrutine og nabovarsel svar i tillegg til kvittering for nabovarsel.

Endringene for nabovarsel kommer ut som ny versjon; versjon 4. I en periode, inntil leverandørene får tilpasset sine løsninger, vil det altså eksistere to sideordnede versjoner av nabovarsel: versjon 3, med svarskjema i versjon 2 og versjon 4, med svarskjema i versjon 3.
Se nærmere beskrivelse her: https://dibk.atlassian.net/wiki/spaces/FB/blog/2019/09/12/731447301

Innhold i releasen:

• Nabovarseltjenesten generelt

  • Exception-håndtering knyttet til 3.-partstjenester (Altinn, KS SvatUt o.likn.) er forbedret og det gjør hele tjenesten mer robust overfor kortvarige utfall

  • Intern logging er forbedret; det gir både bedre mulig til å følge opp avvik og feil, og lage detaljert statistikk over bruken av tjenesten

  • Mengden bytes som transporteres og mellomlagres er vesentlig redusert gjennom en effektivisering av nabovarslingen som også bidrar til en forbedret brukeropplevelse ved at det kun gis et varsel til nabo som har flere eiendommer

  • Det er rettet slik at distribusjonen ikke stopper opp om det er feil på en mottaker. Tidligere var det slik at hele sendingen ble feilmeldt. Nå traverseres listen og kun de distribusjonene som ikke kan gjennomføres merkes som feilet.

• Nabovarsel

  • Rettet slik at det ikke kreves vedlegget “TegningNyFasade“ når tiltakstype gjelder “rivinghelebygg” eller “plasseringmidlertidig” (FBYGG-1606)

  • Meldingen i Altinn innboks: Oversiktelig listing av naboeiendommer, matrikkelidentifikasjon, er implementert (FBYGG-1556)

  • Navngivning arkivreferanse, AR-nummer, er gjort tydeligere; heter nå “Altinnreferanse” (FBYGG-1583)

  • Forbedret intern logging aht feilsøking og bistand til løsningsleverandører (FBYGG-1529)

  • Setter rett adresse i kvitteringen; skal være “gjelder eiendom”-adressen, ikke nabo/fester sin postadresse (FBYGG-1540)

  • Felter som ikke har verdi i xml’en skjules i visningen i Altinn-skjema; gjelder alle nabovarsel-relaterte skjema (FBYGG-1547)

  • Utenlandsk postadresse har nå med navn på land og postnummer prefikses med ISO-3166 Alpha 2 kode etter gjeldende regler. Validering av adressen er strammet inn (FBYGG-1386)

  • Pdf’en i Altinn er forbedret på layout og tekster (FBYGG-1546)

• Nabovarsel svar

  • Det har skapt forvirring at det ser ut som om pdf er signert når man åpner den. Det skal ikke være tilfellet og det er nå korrigert (FBYGG-1630)

  • Stengt for muligheten til å forandre på oppførte eiendommer i skjemaet (FBYGG-1526)

  • Felter som ikke har verdi i xml’en skjules i visningen i Altinn-skjema; gjelder alle nabovarsel-relaterte skjema (FBYGG-1548)

  • “Nabovarsel” har blitt vedlegg til svaret for å øke dokumentasjonsverdien. Gjort noen tekst og presentasjonsforbedringer (FBYGG-1542)

• Kvittering for nabovarsel

  • Lagt inn oversiktelig opplisting (matrise) av matrikkelinformasjon når eiendommen er seksjonert. Rekkefølge på feste- og seksjonsnummer-kolonner er korrigert (var byttet om) (FBYGG-1575/1616))

  • Nabovarslet, som er distribuert, legges ved kvitteringen. Løsningen innebærer en mellomlagring av nabovarslet koplet til kvitteringen (FBYGG-1551)

  • Felter som ikke har verdi i xml’en skjules i visningen i Altinn-skjema; gjelder alle nabovarsel-relaterte skjema (FBYGG-1540)

  • Forbedring av tekster og presentasjon generelt i pdf-'en (FBYGG-1541)

  • Feilmapping av seksjons- og festenummer er rettet (FBYGG-1576)

• Annet:

  • Søknad om tiltak u/ansvarsrett: Tekst ble kuttet i fritekstfelt som var definert som tekstlinje. Det er nå endret til å være en tekstblokk. Dermed unngås kutting av tekst. (FBYGG-1614)

  • RSS-feed til DiBK FtB-bloggen er laget og publisert på … - bloggen, her: https://dibk.atlassian.net/wiki/spaces/FB/blog/2019/09/12/731512922 (FBYGG-1611)

Vi har i den forløpne perioden også endret vår arbeidsmetodikk fra scrum, dvs. sprint-orientert, til kanban. Derfor er også sprint-referansen blitt borte. Denne endringen er gjort fordi FtB nå har beveget seg fra en renere utviklingsfase til en livsfase som består av både utviklingsaktiviteter og vedlikehold av tjenesten. Kanban-tilnærmingen gjør det mulig for oss, på en kontrollert måte, å få ut feilrettinger og oppdateringer i et raskere tempo, samtidig som vi kan fortsette arbeidet med å utvikle resterende deler av tjenesten.