Project

General

Profile

Bug #2530

Problemer med reservering af tidsskrifter

Added by Anonymous over 2 years ago. Updated almost 2 years ago.

Status:
Resolved (tag version)
Priority:
Urgent
Assignee:
Estimated time:
URL med eksempel:
Kategorier:
Søgning - Materialevisning, Min konto - Reserveringer

Description

Vordingborg har indberettet en sag hos DBC som følger:
Det er ikke muligt at reservere tidsskriftet Femina fra nr. 7 2017 og frem til nyeste nr -på vores DDB CMS. Vi får følgende fejlmeddelelse: "Unknown error for library system while attempting to reserve".
Vi har ingen problemer med at reservere de sammen numre via Cicero.
Hvis I vil teste på vores DDB CMS er her en testlåner: 6500048512 pinkode:1111
Fejlen er verificeret af os (DBC) som ikke har kunnet finde noget i div. logs.

Sagen er derfor sendt videre til Systematic der svarer tilbage som følger:

Jeg har observeret en forskel fra nr 8 2017 og frem. Det handler om feltet Volumen i periodikaoplysningerne (herunder kaldet "volume"), som fra nr 8 2017 og frem indeholder en tom streng. Alle tidligere eksemplarer har null stående:
{
"itemNumber": "4842759620",
"available": false,
"periodical": {
"volume": null,
"volumeYear": "2017",
"displayText": "2017, nr. 07",
"volumeNumber": "07"
},
"materialGroupName": "30"
},
{
"itemNumber": "4842760572",
"available": false,
"periodical": {
"volume": "",
"volumeYear": "2017",
"displayText": "2017, nr. 08",
"volumeNumber": "08"
},
"materialGroupName": "30"
},

Jeg vil gætte på at forskellen er introduceret ved at I på abonnementet har skrevet noget i feltet og fjernet det igen, på et tidspunkt mellem registrering af de 2 eksemplarer.
Jeg kan godt oprette reserveringer på begge materialer, hvis bare jeg angiver volumen rigtigt i forespørgslen.

Så min formodning er at DDB ikke sender volumen, eller sender null som værdi, i de tilfælde hvor I ikke kan reservere materialet.

Det samme "skift" i værdien af Volumen-feltet kan ses på eksemplarerne af Euroman hos Allerød. De ser ud til at have samme problem:
http://platform.dandigbib.org/issues/2484


Related issues

Related to DDB CMS - Bug #1455: FBS integration. Reservering af årbog fejlerResolved
Related to DDB CMS - Bug #1460: Reserveringsknap på årbøger giver problemerResolved (tag version)
Related to DDB CMS - Bug #2293: Reservering der fejler mangler oversættelse (FBS)Resolved (tag version)
Related to DDB CMS - Bug #3337: Opdatering af JSON-mapperClosed
Has duplicate DDB CMS - Bug #2484: Reservering af tidsskrifter fejlerClosed

History

#1 Updated by Simon Holt over 2 years ago

Vil bare lige hurtig nævne, at jeg også har observeret problemer med reserveringer af flere tidskrifter på vejlebib.dk

Jeg er ikke helt færdig med at analysere problematikken endnu, men det er præcis den samme fejlmeddelelse og også på tidskrifter årgang og numre.

#2 Updated by Rolf Madsen over 2 years ago

  • Status changed from New to Needs analysis
  • Target version set to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

#3 Updated by Rolf Madsen over 2 years ago

  • Has duplicate Bug #2484: Reservering af tidsskrifter fejler added

#4 Updated by Rolf Madsen over 2 years ago

  • Assignee set to Simon Holt

Jeg tillader mig at assigne dette issue til dig Simon.

Vil du assigne tilbage til mig hvis jeg har misforstået og det ikke er en du når at analysere, så sender vi den videre til et udviklingshus.

#5 Updated by Rolf Madsen over 2 years ago

  • Target version changed from Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) to Release 27 - Bugfixes (Inlead)

#6 Updated by Simon Holt over 2 years ago

Det er i orden. Jeg kigger på den!

#7 Updated by Martin Cording over 2 years ago

Dette issue minder utrolig meget om #1455. Jeg vil foreslå at dette lukkes og #1455 udvides til at dække over både årbøger og tidsskrifter.

#8 Updated by Simon Holt over 2 years ago

Ja det ser ud til at være samme problematik, men den opstår af forskellige årsager.

Jeg var gået i gang med at kigge på den her, men det viser sig at være et større problem i den anden sag.

#9 Updated by Simon Holt over 2 years ago

> Så min formodning er at DDB ikke sender volumen, eller sender null som værdi, i de tilfælde hvor I ikke kan reservere materialet.

Det ser ud til at være rigtig (jvf. min kommentar her: http://platform.dandigbib.org/issues/1455#note-44)

Har ikke gravet helt i bund endnu, men det lader til at DDB CMS faktisk ikke har mulighed for at skelne imellem tom streng og NULL.

#10 Updated by Simon Holt over 2 years ago

Det er lidt noget vrøvl jeg skriver i ovenstående. Som det også fremgår af beskrivelsen i denne sag, er der null-værdier i det "rå" json der returneres fra FBS API'et.

Denne null-værdi går desværre tabt i JsonMapper, som vi bruger til at mappe svaret fra API'et til data-modellen. Jeg ved ikke meget om koden, men har xdebug'et mig frem til at null-værdi ser ud til at gå tabt her ved kaldet til settype:

https://github.com/cweiske/jsonmapper/blob/v0.4.4/src/JsonMapper.php#L121

Så vidt jeg kan se er værdien null op til da og efter er det en tom streng. Hvis vi kunne få den null-værdi ud til FBS, kunne vi i _fbs_periodical_get_local_id() skelne imellem om vi skal sende tom streng eller NULL til FBS ved reservation.

Jeg tror vi skal have reload til at kigge på det her.

**Edit: Jeg kan se nyere versioner af JsonMapper indeholder noget halløj med nullable types. Måske kan en opdatering fikse det (den version vi bruger er 0.4.4. Nyeste version er 1.2.0)

#11 Updated by Steen Larsen over 2 years ago

Jeg tror det er _fbs_periodical_parse_local_id / _fbs_periodical_get_local_id (i fbs.module) du skal kigge på og som håndterer "encode"/"decode" mht år,volumen,nummer - og det er dér empty optræder.

Jeg kunne forestille mig (men ikke testet) at hvis null encodes til '-' så skal den tomme streng blot encodes til noget andet neutralt og efterfølgende decodes på passende vis. Det er vigtigt at den tomme streng faktisk oversættes til noget, da tricket med :: sandsynligvis ellers vil fejle.

#12 Updated by Rolf Madsen over 2 years ago

  • Status changed from Needs analysis to Ready for development
  • Assignee changed from Simon Holt to Christel Krabbenhøft

Vi prøver at høre Reload om Thomas har tid i dag!

#13 Updated by Christel Krabbenhøft over 2 years ago

  • Assignee changed from Christel Krabbenhøft to Thomas Hansen
  • Target version changed from Release 27 - Bugfixes (Inlead) to Release 27 - Bugfixes (Reload)

#14 Updated by Simon Holt over 2 years ago

Tak for det, Rolf.

> Jeg tror det er _fbs_periodical_parse_local_id / _fbs_periodical_get_local_id (i fbs.module) du skal kigge på og som håndterer "encode"/"decode" mht år,volumen,nummer - og det er dér empty optræder.

Ja, det er i _fbs_periodical_get_local_id() det bestemmes, hvad der efterfølgende sendes med af periodica-oplysninger ved reservation. Hvis kan differentiere kan vi sende det rigtige afsted.

> Det er vigtigt at den tomme streng faktisk oversættes til noget, da tricket med :: sandsynligvis ellers vil fejle.

Rendte også ind i denne problematik i går og satte et mellemrum i dette tilfælde. Det så ud til at virke.

#15 Updated by Thomas Hansen over 2 years ago

suk Nogen har vist ikke hørt om "Be strict in what you emit, lenient in what you accept reglen"...

Jeg kigger på det. Muligvis finder på en anden måde at encode istedet for at hacke den gamle til.

#16 Updated by Thomas Hansen over 2 years ago

  • Status changed from Ready for development to Needs code review

https://github.com/ding2/ding2/pull/696

Utestet da jeg ikke lige har passende test data.

#17 Updated by Simon Holt over 2 years ago

Fedt, Thomas!

Vil lige se om jeg kan få tid til at teste det i dag ellers bliver det mandag.

#18 Updated by Rolf Madsen over 2 years ago

  • Assignee changed from Thomas Hansen to Gitte Barlach

#19 Updated by Steen Larsen over 2 years ago

Hvordan gik det med at vise / behandle materialet som periodika (årgange/numre) hvis FBS-API fortæller at det er et sådan materiale og ellers som almindelig materiale hvis det ikke er?

Der vil stadig være værker der ikke kan reserveres i FBS API (og derfor heller ikke i ddbcms) som beskrevet i de andre sager #1455, #1460 men med det nyeste pullrequest og manuelt at rette de enkelte poster skulle de kunne reserveres.

#20 Updated by Simon Holt over 2 years ago

Korrekt, langt de fleste periodikum skulle kunne reserveres med det nye PR.

Det med om DDB CMS skal være i stand til at håndtere periodikum forskelligt (#1455, #1460), afhænger af om Systematic/Kombit vil fortage en ændring i systemet.

Så vi kan vel se den som resolved fra vores side, da vi uanset udfaldet ikke kan gøre så meget ved det i DDB CMS.

#21 Updated by Simon Holt over 2 years ago

Har testet PR fra http://platform.dandigbib.org/issues/2530#note-16.

Det spiller bare nu!

Har testet med et nummer af Euroman ved at fjerne periodica oplysninger fra nummer-feltet i Cicero, så det dermed bliver en tom streng. Det korrekte periodica objekt, der skal sendes med ved reservation, bliver dermed:

periodical->volume =
periodical->volumeYear = (string) 2015
periodical->volumeNumber =

Og det er præcist det der sendes med og reserveringen går lige igennem!

Tør godt love nu at reservering af alle tidsskrifter virker, hvis bare periodica-oplysninger er anført i mindst et felt på materialerne i Cicero.

#22 Updated by Carsten Vilhelmsen over 2 years ago

Tårnby har konstateret det samme problem med "Alt om haven" - i dette tilfælde opstår problemet i overgangen til 2017/1

#23 Updated by Simon Holt about 2 years ago

Vi skal have PR fra #note-16 i denne sag merget hurtigst som muligt. Det fikser rigtig mange af disse problemer med reservering af tidsskrift. Efter rettelsen er kommet med, er det kun hvis der slet ikke er nogle periodica-oplysninger angivet i Cicero under behold og materialet er ma=pe, at det vil fejle.

#24 Updated by Steen Larsen about 2 years ago

  • Description updated (diff)

Jeg har implementeret rettelserne på vores stg-server - dvs de to pull-request

https://github.com/ding2/ding2/pull/353
https://github.com/ding2/ding2/pull/696/

samt opdatering af jsonmapper til 1.2

De stammer fra sagerne #1455#note-10 og #2530#note-16

Det fejlede ved login og f.eks. denne fejl blev vist:

jsonMapper_Exception: JSON property "postalCode" in class "FBS\Model\Address" must not be NULL in JsonMapper->map() (line 199 of . /libraries/jsonmapper/src/JsonMapper.php).


Årsagen ligger i opdateringen af jsonmapper med det tilhørende rettelser af filerne i modules/fbs/src/ - her har en del filer fået tilføjet "|null" men det mangler flere steder.

Jeg har fundet disse hvor det mangler:

  • preferredPickupBranch
  • postalCode
  • street
  • city
  • country

Jeg har kun fundet dem så jeg kunne logge ind og ved ikke om der mangler flere i andre sammenhænge.
I første omgang havde mit lånerkort ikke defineret noget i adressefelterne for den sekundære adresse, så det fejlede. I anden omgang startede jeg med et blankt lånerkort med mindst muligt indtastet for at se hvilke felter der så dukkede op i fejlbeskeden.

Efter min manuelle rettelse med "|null" kunne jeg gennemføre reserveringen.

#25 Updated by Gitte Barlach about 2 years ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Thomas Hansen

Thomas, kan du se på denne igen ?

#26 Updated by Simon Holt about 2 years ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Thomas Hansen to Gitte Barlach

Har lige prøvet at søge modules/fbs/src/model igennem for linjer med @var uden null (med et regex: ^(?=.*@var)(?!.*null).*).

Den finder 129 tilfælde (kan godt supplere med en liste hvis det er).

Grunden til det ikke var et problem før, var fordi null-værdien gik tabt og den bare konverterede til tom streng. Nu smider den altså en exception, hvis man ikke har angivet at en property må være null. Så der kan altså gemme sig nogle fejl, i de forskellige situationer hvor systemet interagerer med FBS API'et.

Spørgsmålet er om det ikke bare er det nemmeste/sikrest at tillade null alle steder?

@Thomas bliver det med om null er tilladt auto genereret eller har du selv manuelt tilføjet det?

 

#27 Updated by Rolf Madsen about 2 years ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Gitte Barlach to Christel Krabbenhøft
  • Priority changed from Normal to Urgent

#28 Updated by Christel Krabbenhøft about 2 years ago

  • Assignee changed from Christel Krabbenhøft to Thomas Hansen

#29 Updated by Thomas Hansen about 2 years ago

FBS modulet laver ikke noget med Address klassen. Jeg har checket i koden, og der er ingen referencer til klassen.

Så det Address objekt den kløjs i må komme som en del af det svar vi får fra authenticate. Den langer en Patron over der har op til flere addresser.

Så problemet lader til at være at FBS giver os en Address der ikke overholder deres egen specifikation af modellen. Det kan bekræftes ved at checke det svar vi får fra FBS og se om der ikke ligger en null værdi i postalCode.

Spørgsmålet er om det ikke bare er det nemmeste/sikrest at tillade null alle steder?

Nemmest, måske, sikrest, absolut ikke.

@Thomas bliver det med om null er tilladt auto genereret eller har du selv manuelt tilføjet det?

Det kommer fra Swagger specifikationen.

Medmindre det viser sig at det ikke kommer fra FBS' svar, så er der ikke så meget vi kan gøre. Hvis vi begynder at hacke Swagger spec'en kan vi ligesågodt se i øjnene at der så ikke *er* nogen spec, og vi er tilbage til de glade cowboy dage med alma hvor folk gættede sig til hvad den ville have og håbede det bedste.

 

#30 Updated by Steen Larsen about 2 years ago

Jeg har oprettet sag hos Systematic med de fundne fejl og nævnt at der stadig kan være andre felter som også er null på trods af swagger-specifikationen. Sagsnr: 55687

#31 Updated by Rolf Madsen about 2 years ago

Jeg har lige tjekket vores testbruger "Brian Birkely DDB" hvor postal code er udfyldt:

 "postalCode": "2670",

#32 Updated by Rolf Madsen about 2 years ago

  • Status changed from Reviewed - Needs info/rework to Systematic (waiting)

Har jeg ret i at korrekt status her faktisk er Systematic (waiting)?

#33 Updated by Rolf Madsen about 2 years ago

  • Related to Bug #1455: FBS integration. Reservering af årbog fejler added

#34 Updated by Rolf Madsen about 2 years ago

  • Related to Bug #1460: Reserveringsknap på årbøger giver problemer added

#35 Updated by Anonymous about 2 years ago

Jeg har oplevet en tilsvarende fejl med Costume:

Hvis man på vores hjemmeside forsøger at reservere et af de 6 nyeste årgange af tidsskiftet Costume, faustnr. 24153886, får man en fejlmeddelelse: Unknown error from library system while attempting to reserve.
 
Når jeg kigger i Cicero, har de to nyeste årgange én materialegruppe, som er reserverbar men ikke kan udlånes, og de øvrige har samme gruppe som alle de gamle årgange, der både kan lånes og reserveres.
 

Jeg har skrevet til DBC og fejlmeldt, og de svarede:

"Når jeg forsøger at reservere et nummer af pågældende tss fås følgende fejl i loggen:
 
ddbwww-p84: Nov  1 13:35:27 https://hvidovre.ddbcms.dk|1509539727|fbs|172.16.5.127|https://hvidovre.ddbcms.dk/ting/object/716700-katalog%3A24153886/reserve/ZmJzLS06MjAxNzoxODI6MjQxNTM4ODY%3D/MjAxNw%3D%3D/LTE4Mg%3D%3D|https://hvidovre.ddbcms.dk/ting/object/716700-katalog%3A24153886|7||Unexpected state "no_reservable_materials" on failed reservaiton
 
Dvs. at DDB-CMS'et får besked fra Cicero om at de er "no reservable materials" på den pågældende post. Derfor må fejlen findes i Cicero - hvadenten det er eksemplaret der er noget uregelmæssigt ved eller det er en mulig fejl.

/Hans Erik"

Dette svar sendte jeg så til Systematic, der med det samme lukkede sagen med denne kommentar:

"Hej

Vi er overbeviste om at fejlen ligger hos DDB-CMS

Prøv at se på denne:

https://platform.dandigbib.org/issues/2530


/Afshin"

#36 Updated by Steen Larsen about 2 years ago

@Rolf - ja, vi venter på en opdatering fra Systematic om de de vil levere en korrekt Swagger definition

@Tina - det ser ud til at dit eksempel netop er fejlen hvor FBS api udleverer en tom streng fra et af periodica-felterne (år/volumen/nummer) som ddbcms ikke kan håndtere.

#37 Updated by Simon Holt about 2 years ago

Har lige læst releasenote for Cicero 1.8.3:

Under 3.3: Fejl rettet i releasen:

FBS-8409: Reservation på periodika uden eller med tom værdi i periodika
information (vol., nr. og år) kan nu igen oprettes via ddbcms (ekstern
API) uden fejl.

 

Så det lader til at være rettet. Bliver spændende at teste :)

#38 Updated by Gitte Barlach about 2 years ago

  • Status changed from Systematic (waiting) to Ready for development

#39 Updated by Gitte Barlach about 2 years ago

Cicero opdateres i nat

#40 Updated by Rolf Madsen about 2 years ago

  • Status changed from Ready for development to Technical test
  • Assignee deleted (Thomas Hansen)

#41 Updated by Simon Holt almost 2 years ago

Nå men jeg testede lige i 1.8.4 ifb med denne tråd på fb: https://www.facebook.com/groups/ddbcms/permalink/627367370771589/

Der ser desværre stadig ud til at være problemer med tom streng/null.

Tog et af de ældste udgaver af Euroman og fjernede Nummer fra periodikaoplysninger i Cicero. Materialet burde stadig kunne reserveres, da Årgang er angivet, men den giver fejl ved reservation.

#42 Updated by Steen Larsen almost 2 years ago

Lige en lille opsummering af de kendte tss-fejl

  1. hvor man har rettet år/volumen/nummer (tss-felterne) således at et af dem indeholder den tomme streng fremfor null-værdien (eller også var det omvendt?)
  2. hvor posten er et tidsskrift (ifølge brønden/marcposten) men der var ingen oplysninger i nogle af tss-felterne (altså null i alle 3 felter)
  3. hvor posten ikke er et tidsskrift men der er oplysninger i et (eller flere) af tss-felterne (tss-felterne vises dog ikke på materialevisning i cicero)

Jeg tror det må være 1. (eller noget af den) der måske er løst med 1.8.3 hvorimod 2+3 sandsynligvis stadig kræver en manuel håndtering: 2) hvor man tilføjer noget i ét af tss-felterne og 3) hvor posten kasseres og derefter oprettes igen.

Jeg har rykket for problemstillingen vedr forkert Swagger-definition (note 30 ovenfor) - løsningen skulle komme i en release i januar måned (2018). Fejlen hedder i deres system: Låner administration: mismatch mellem CMS API og Cicero.

#43 Updated by Simon Holt almost 2 years ago

Lyder betryggende, at der er en sag omkring det :)

Jeg tilføjede følgende i ovenstående kommentar:

Tog et af de ældste udgaver af Euroman og fjernede Nummer fra periodikaoplysninger i Cicero. Materialet burde stadig kunne reserveres, da Årgang er angivet, men den giver fejl ved reservation.

Så det tyder altså på det er 1.

#44 Updated by Steen Larsen almost 2 years ago

Så problemet (med 1) er at for at kunne håndtere tom streng/null så skulle jsonmapper opdateres og det betød til gengæld at swagger-definition ikke var korrekt i forhold til f.eks. lånere. Så den afventer vi nu.

Forresten 2/3 er svære at finde men har man først fat i materialet er det nemt at se - 2) hvor der mangler info i tss-felterne i materialevisning og 3) hvor titlen har tilføjet årgangsinfo i () i søgeresultatsiden.

#45 Updated by Simon Holt almost 2 years ago

Var ikke bekendt med 3. og hvordan den kunne observeres/findes. Det må jeg lige have kigget på.

#46 Updated by Rolf Madsen almost 2 years ago

  • Related to Bug #2293: Reservering der fejler mangler oversættelse (FBS) added

#47 Updated by Rolf Madsen almost 2 years ago

  • Status changed from Technical test to Reviewed - Needs info/rework
  • Assignee set to Simon Holt

Jeg har tilladt mig at ændre assignee til Simon og status til Needs rework, sig til hvis det ikke er korrekt.

#48 Updated by Simon Holt almost 2 years ago

@Rolf det er fint du assignet til mig. Kunne nemlig godt tænke mig at tage et ekstra dybdegående kig på det efter ændringerne i Cicero 1.8.3.

#49 Updated by Steen Larsen almost 2 years ago

Sagen hos Systematic nævnt ovenfor i note #2530#note-24 har jeg fået at vide er løst i 1.9.

I releasenote står vedr CMS API: "Lånerens sekundære adresse leveres ikke længere i CMS beskeder, hvis ingen af de tilhørende felter er udfyldt."

Der er ikke sket en opdatering af swagger-definitionen jvf dato på http://fbsudrulning.dk/partner-bogen/

 

Jeg tvivler lidt om denne rettelse faktisk løser det, f.eks. hvis afhentningsfilial er tom (jvf noten ovenfor) så kunne man ikke logge ind. Jeg har pt. ikke mulighed for at teste det.

#50 Updated by Steen Larsen almost 2 years ago

Opdateringen i FBS 1.9.1 som blev lagt på i går aftes løser problemet med tom streng vs null. Nu leverer FBS-api ikke tomme strenge men null istedet.

Tom streng opstod når man rettede/slettede indhold i et af felterne år/nummer/volumen og det kunne ddbcms ikke håndtere.

Det betyder at tidligere numre der ikke kunne reserveres før nu kan reserveres. Testet på vores hjemmeside og testet direkte via FBS-API i går og i dag.

FBS 1.9.1 løser ikke fejlen med tidsskrifter der hvor alle år/nummer/volumen er tomme (#1460) eller monografier med overflødig information i år/nummer/volumen (#3247).

#51 Updated by Simon Holt almost 2 years ago

Jamen det er jo herligt!

Har også lige testet med et par poster, som altid har givet fejl før. Og nu går reservationen lige igennem.

#52 Updated by Christel Krabbenhøft almost 2 years ago

  • Target version changed from Release 27 - Bugfixes (Reload) to Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

#53 Updated by Rolf Madsen almost 2 years ago

Er det korrekt forstået af ovenstående at status på dette issue faktisk kan ændres til Resolved (tag version)?

#54 Updated by Steen Larsen almost 2 years ago

Ja, men jeg er tvivl om de pullrequest (2) der er i sagen som der måske/måske ikke er brug for alligevel. Der er også opdateringen af json-mapper som gav ekstra udfordringer.

Men dem skal vi vel blot huske når vi opretter ny sag med henblik på opdatering af swagger og (måske) json-mapper.

 

#55 Updated by Rolf Madsen almost 2 years ago

  • Target version changed from Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) to Release 29-2 - Bugfixes (7.x-4.5.0)

#56 Updated by Gitte Barlach almost 2 years ago

  • Assignee changed from Simon Holt to Steen Larsen

Steen kan jeg lokke dig til at oprette en ny sag på det, du mener stadig skal rettes?
 

#57 Updated by Simon Holt almost 2 years ago

Tog lige et hurtig kig på denne. De to PR er:

1. https://github.com/ding2/ding2/pull/353

Jeg har kigget på koden og er faktisk lidt i tvivl om hvad den helt præcist løser. Ser ud til at være noget bedre håndtering af default-værdier og så bruger den periodical display text, der returneres fra FBS API'et.

Uanset hvad, så er rettelsen blevet merget og det ser ud til at virke med den seneste opdatering af FBS.

2. https://github.com/ding2/ding2/pull/696/ 

Denne opdaterer JSON-mapper fra 0.4.4 til 1.2.0 og er IKKE blevet merget. Kan muligvis give anledning til nye fejl, når DDB CMS kommunikere med FBS API'et. Så skal testes grundigt.

@Steen det vil vel være oplagt at lave en ny sag vedrørende opdatering af JSON-mapper hvor det relaterede PR overføres til?

#58 Updated by Rolf Madsen almost 2 years ago

  • Status changed from Reviewed - Needs info/rework to Resolved (tag version)

Simon laver et nyt issue omkring JSON mapper.

Dette issue er dermed resoved og status ændret tilsvarnede.

#59 Updated by Simon Holt almost 2 years ago

  • Related to Bug #3337: Opdatering af JSON-mapper added

Also available in: Atom PDF