Project

General

Profile

Bug #3936

Visning af fjernlån i lånerstatus (reserveringer og lån) fejler og giver "Error: missing/unknown/inaccessible record..." LØSES MED #4512

Added by Carsten Vilhelmsen about 1 year ago. Updated 2 months ago.

Status:
Resolved (tag version)
Priority:
High
Assignee:
Target version:
Estimated time:
URL med eksempel:
Kategorier:
Min konto - Brugerprofil

Description

Efter den seneste opdatering er titlen på reserverede fjernlån fejlagtig/manglende (Error, missing..)

res_fjernlån.PNG (26.7 KB) res_fjernlån.PNG Carsten Vilhelmsen, 11/14/2018 03:11 PM
fjernlaan.jpg (21.9 KB) fjernlaan.jpg Susanne Lund Mikkelsen, 11/20/2018 11:04 AM
Fejl visning af fjernlån.JPG (16.2 KB) Fejl visning af fjernlån.JPG Pernille Kirsten Wuttke, 12/07/2018 11:35 AM
Fejl visning af fjernlån på www.fkb.dk.png (39.5 KB) Fejl visning af fjernlån på www.fkb.dk.png Pernille Kirsten Wuttke, 12/07/2018 11:35 AM
fjernlånsres_error_missing.png (109 KB) fjernlånsres_error_missing.png Gitte Barlach, 02/28/2019 03:17 PM
Fjernlånsreservering_error_missing.jpg (415 KB) Fjernlånsreservering_error_missing.jpg Gitte Barlach, 02/28/2019 03:17 PM
forkertfjernlaanstitel.JPG (55.6 KB) forkertfjernlaanstitel.JPG Melissa Wieser, 06/27/2019 10:31 AM

Related issues

Related to DDB CMS - Bug #4041: Sletning af reservering udløser fejlResolved (tag version)
Related to DDB CMS - Bug #4111: Mellemværende vedr fjernlån vises ikke korrekt i lånerstatusClosed
Related to DDB CMS - Bug #4212: Opensearch getObject returnerer fejlsvar som rigtige objekterNeeds code review
Related to DDB CMS - Bug #4413: Fjernlån fra fag- og forskningsbiblioteker giver fortsat "unknown/missing/inaccessible record"Resolved
Related to DDB CMS - Bug #4512: Opgrader til https://opensearch.addi.dk/b3.5_5.2/Ready for development
Has duplicate DDB CMS - Bug #3968: Problem med manglende titler i lånerstatus efter opdatering til den nye releaseClosed
Has duplicate DDB CMS - Bug #4046: Error: unknown/missing/inaccessible record - Poster fra Det kongelige bibliotek - AarhusClosed

History

#1 Updated by Simon Holt about 1 year ago

Vil du skrive det faust nummer, som man ikke kan se på screenshot?

#2 Updated by Carsten Vilhelmsen about 1 year ago

Den kommer her 870970-basis:2789829

#3 Updated by Simon Holt about 1 year ago

Den her post eksisterer ikke i brønden længere (overhovedet). Teskten "Error: unknown/missing/inaccessible record: 870970-basis:2789829" er faktisk den titel opensearch returnerer for posten.

Kan du se noget om den i bibliotekssystemet?

Kan godt ske vi lige skal have arbejdet lidt med den feedback, der præsenteres til brugerne i disse tilfælde.

#4 Updated by Carsten Vilhelmsen about 1 year ago

Jeg har lige tjekket med et fjernlån som ligger i brønden, der er ingen problemer med visningen.
 

Jeg er enig i at feedbacket godt kunne formidles bedre :)

 

#5 Updated by Simon Holt about 1 year ago

Ja, det må vi lige have kigget på.

Er meget interesseret i at høre, hvordan posten ser ud i bibliotekssytemet på låneren. Kan Cicero vises noget om materialet i Jeres system?

 

#6 Updated by Rolf Madsen about 1 year ago

  • Status changed from New to Development
  • Assignee set to Simon Holt
  • Target version set to Release 31 - bugfixes

#7 Updated by Susanne Lund Mikkelsen 12 months ago

Vi oplever samme problem i Køge. Jeg har vedhæftet et screendump fra en af mine kollegaer. Der er kun et materialenummer at gå ud fra.

Faustnummeret for posten med materialenummeret 400023440979 er 3542987.

 

 

#8 Updated by Simon Holt 12 months ago

@Susanne Kan du se noget om materialerne i bibliotekssystemet? F.eks. på låneren i listen over udlån. Kan du f.eks. se materialernes titel der?

 

Ja, jeg kan se både titel og forfatter, når jeg er inde på låneren i Cicero.

#9 Updated by Susanne Lund Mikkelsen 12 months ago

Undskyld, jeg kom til at rette i dit svar i stedet for at citere

 

#10 Updated by Simon Holt 12 months ago

hehe helt ok.

Cicero må altså ligge inde med nogle oplysninger vi kan bruge i disse tilfælde. Er lige ved at se, om jeg kan få sat et par testlån op.

Det her må ske fordi det långivende bibliotek kasserer materialet og hvis de er det eneste der har beholding på det, bliver det slettet i brønden efterfølgende. Nogle der har en bedre forklaring?

#11 Updated by Simon Holt 12 months ago

Har fundet et eksempel på et materiale i vores bibliotekssystem, som ikke har en associeret post i brønden. Også i forbindelse med et fjernlån.

Det ser ud til at fjernlånet stammer fra statsbiblioteket og en eller anden underlig grund har fået et andet faust-nummer, som ikke er korrekt (kun på 7-cifre ikke 8). Posten eksisterer faktisk i brønden, men i vores system er materialet associeret med et forkert faustnummer.

@Susanne de fjernlån I har problemer med. Stammer de fra statsbiblioteket eller hvor stammer de fra?

#12 Updated by Susanne Lund Mikkelsen 12 months ago

Det kunne godt se sådan ud. Eksemplet fra min kollega er et fjernlån fra statsbiblioteket, og derudover har jeg fået en henvendelse fra en låner, som har en del fjernlån fra statsbiblioteket.

 

#13 Updated by Simon Holt 12 months ago

Kan du søge posten frem på fjernlåns ID i BOB-basen? For at se om den har et andet gyldigt faustnummer, som rent faktisk er søgbart i brønden?

#14 Updated by Susanne Lund Mikkelsen 12 months ago

Her er et eksempel fra bob-basen - i Cicero har bogen fået faustnummer 3542987

 

Sketching - 2008

 

BOG - London, Collins, 2008. - 96 s. : ill. (some col.), 16 x 20 cm.
- (Collins 30-minute)
Idnr: 3542987
ISBN: 9780007259380
ISBN: 0007259387

 

Alwyn Crawshaw
96 s. : ill. (some col.), 16 x 20 cm.
ISBN: 9780007259380, pris: £7.99
ISBN: 0007259387, pris: £7.99
Id-nr.: 3542987

 

#15 Updated by Simon Holt 12 months ago

Mit gæt er, at statsbiblioteket opererer med nogle andre faustnumre end dem folkebibliotekerne bruger i brønden. Disse faustnumre er ikke søgbare i brønden.

I nogle tilfælde kan den faktisk godt finde en associeret faustnummer i brønden og vise det i netpunkt. I de tilfælde du kommer med, ser det ud som om den ikke har fundet et andet faustnummer.

Under alle omstændigheder bruger Cicero det faustnummer der ikke er søgbart i brønden (det 7-cifrede), når den modtager fjernlån fra statsbiblioteket. I vores tilfælde hvor det rent faktisk var et 8-cifret søgbart faustnummer, brugte den heller ikke dette.

Den umiddelbare løsning må være, at vi bruger de sparsomme informationer Cicero måtte have om materialet, når det ikke er søgbar i brønden. Så kan vi i det mindste vise titel/forfatter på statuslisten, men vi kan altså ikke linke til materialet.

Men jeg synes altså det virker lidt underligt det har sammenspil imellem Cicero og statsbiblioteket.

#16 Updated by Jeanette Jensen 12 months ago

Jeg har 2 eksempler på dette issue, som ikke er fra statsbiblioteket.

- mat.nr: 550202066623 og faust: 1567336 "Nansen : oppdageren" fra Syddansk universitetsbibliotek

- mat.nr: 4112245109 og faust: 1031422092 "Symphonie Nr. 9 in vier Sätzen, für großes Orchester (1910)" fra Det Kongelige danske musikkonservatorium

 

#17 Updated by Steen Larsen 12 months ago

Vi skal lige huske at værker udlånt fra f.eks. forskningsbibliotekerne ikke har FAUST-numre - de har jo deres eget system. Ganske vist kan man søge i feltet Faust-nr i FBS/Cicero Fjernlån men det skal vist ikke tages så højtideligt.

Et eksempel på et værk: 850160-katalog:000413911

Prøv at søge efter 000413911 på (nyt) netpunkt og der dukker 5 forskellige værker op fra 5 forskellige agency. Godt vi ikke kan søge dem i brønden.

Der kan sikkert være sammenfald mellem id fra forskningsbibliotekerne og faustnumre - hvorfor ikke? og så kan der jo godt nok komme noget støj. I det her tilfælde hvor nummeret er 9-cifret og starter med 0 ligner det dog ikke et faust-nummer.

Er fjernlånet fra et folke/fbs-bibliotek så vil id'et jo netop være et faustnummer og det vil opføre sig i brønden som alle øvrige faustnumre.
Og når det er slettet eller ingen beholdning på give de samme problemer som hvis man søger efter det på normal vis.

#18 Updated by Steen Larsen 12 months ago

Nu har jeg kigget på numrene ovenfor og søgt dem frem i netpunkt (Symphonie kunne jeg ikke finde et passende match på nummeret)

  • 820010-katalog:2789829
  • 820010-katalog:3542987
  • 820030-katalog:1567336

Det ser ud til at 2789829 (fra note 2) har fået et forkert prefix på.

#19 Updated by Simon Holt 12 months ago

Der kan sikkert være sammenfald mellem id fra forskningsbibliotekerne og faustnumre - hvorfor ikke?

Det er jo lidt noget rod. På statuslisterne får vi jo kun det id og betragter det som et faust, når vi prøver at finde pid. Hvordan skal vi kunne skelne imellem de forskellige typer af id'er, hvis der er sammenfald?

Det ser ud til at 2789829 (fra note 2) har fået et forkert prefix på.

Når vi slår de har id'er op med getObject eller rec.id søgning, får vi ikke noget resultat og dermed ikke noget prefix. I koden falder den derfor tilbage på basis namespace.

#20 Updated by Steen Larsen 12 months ago

Men ved reserveringer og lån findes felterne loanType/ilBibliographicRecord i api-svaret som kan pege på et fjernlån og så skal brønden vel slet ikke spørges. Men vi kunne selvfølgelig godt spørge, hvis id'et ligner et faust og ellers ikke.

Feltet loanType har værdien "interLibraryLoan" for fjernlån og ilBibliographicRecord er udfyldt med forfatter/titel m.m.

Det er muligt at nogle fjernlån gennem tiden fejlagtigt har været registreret som egne lån i FBS (der har været forskellige fejlrettelser som kunne tyde på det) men generelt skulle de to felter være ok.

NB: for mellemværende er der derimod intet der viser om det er fjernlån bortset fra evt "mærkelige" recordid'ere eller (afhængig af biblioteket) af materialegruppen.

#21 Updated by Simon Holt 12 months ago

Ok, dem må vi prøve at kigge efter på lån og reservering. 

På lån bliver det sendt med fra FBS provider, men der må gå et eller andet galt i ding_loan. Jf.: https://github.com/ding2/ding2/blob/master/modules/fbs/includes/fbs.loan.inc#L99 

Ligeledes på reservering. Jf.: https://github.com/ding2/ding2/blob/master/modules/fbs/includes/fbs.reservation.inc#L101

Det der så er udfordringen er, at vi for nogle (eller mange) fjernlån rent faktisk kan søge dem frem og tilbyde et link ind til posten. Det kan vi ikke med dem, som ikke kan fremsøges. Så mener heller ikke det er holdbart bare at bruge informationen fra FBS ilBibliographicRecord hvis den er sat under alle omstændigheder. Vil stadig mene vi har behov for at skelne imellem id'er der kan søges i brønden uden fare for sammenfald.

Alternativt skulle vi helt droppe at linke til materialet for alle fjernlån og så bare bruge ilBibliographicRecord i alle tilfælde.

NB: for mellemværende er der derimod intet der viser om det er fjernlån bortset fra evt "mærkelige" recordid'ere eller (afhængig af biblioteket) af materialegruppen.

Kan vi sige noget om disse id'er. Er normaler FAUST på 8 cifre og de andre på 7 og 9?

#22 Updated by Steen Larsen 12 months ago

Jeg kan ikke vurdere om der skal linkes eller ej - men mht til faustnummeret så vil dette regexp-udtryk dække: /^1?\d{8}$/

Det vil dog medtage numre der starter med 9 (og de findes ikke mere) og 9-cifrede numre som starter med 13-19 (de er endnu ikke set i det vilde). Vi (Aarhus) har heller nogle numre der starter med 6 eller 8 så måske er der nogle yderligere begrænsninger i faust som vi kunne udnytte men som jeg ikke kender.

 

#23 Updated by Simon Holt 12 months ago

Tak for det Steen. Er det noget vi kan regne med eller er det bare en konvention, der følges?

Vi er vel ved at være ude i, at der skal tages en beslutning ala:

1. Skal vi fortsætte med at linke ind til posten for fjernlån på statussiderne for de poster, hvor det er muligt (gyldigt faust. Kan søges i brøden)

2. Skal vi helt droppe at linke fjernlåns poster og altid bare bruge det fjernlånsdata FBS API udleverer og således undgå at skulle undersøge om det er gyldigt faust og kan søges i brønden?

Dertil er der også problemet med "normale" materialer, der er helt slettet fra brønden og hvordan vi skal håndtere dem. Men ved ikke om det er lidt uden for scope i denne sag?

#24 Updated by Steen Larsen 12 months ago

Det er en empirisk udledning baseret på lang tids observation af faustnumre og som ikke tager højde for fremtidige værdier.

DBC må kunne kvalificere hvad der er gyldige faustnumre og i hvor stort omfang der er overlap med andre agencys id'ere.

#25 Updated by Rolf Madsen 12 months ago

  • Has duplicate Bug #3968: Problem med manglende titler i lånerstatus efter opdatering til den nye release added

#26 Updated by Lotte Tøstesen 12 months ago

Jeg har lige testet på mig selv, og det sjove er, at titlen på reservationen ikke kan ses i CMS'en, men GODT kan ses i App'en. Mine kollegaer siger, at der gælder det samme mht manglende titler på fjernlån som hjemlån. 

#27 Updated by Pernille Kirsten Wuttke 12 months ago

Lotte Tøstesen skrev:

Jeg har lige testet på mig selv, og det sjove er, at titlen på reservationen ikke kan ses i CMS'en, men GODT kan ses i App'en. Mine kollegaer siger, at der gælder det samme mht manglende titler på fjernlån som hjemlån. 

 

Nu blander jeg mig også lige: vi har samme problem på Frederiksberg. Sådan set har vores side længe fejlet i f t at vise forsidebillede, forfatter og materialetype på fjernlån, så CMS'en i stedet har kopieret de data fra et FRB-materiale ovenover til stor forvirring hos låner. Det nye er fejlbeskede og at det nu kun er materialenummeret, som er tilgængeligt, samt årgang+nr på tidsskrifter. Det gælder både udlånslister og liste med reserveringer.

Eksemplet fra os findes heller ikke i CICERO på FAUST 008806311/ materialenummer 4996477326, men alle oplysninger er tilgængelige på låners status, og posten ligger i bibliotek.dk. Denne er fra det Kongelige Bibliotek.

#28 Updated by Simon Holt 12 months ago

Jeg har fået sat nogle fjernlån op. Jeg ser om jeg kan nå at kigge på det i dag!

#29 Updated by Pernille Kirsten Wuttke 12 months ago

Simon Holt skrev:

Jeg har fået sat nogle fjernlån op. Jeg ser om jeg kan nå at kigge på det i dag!

 

Tak for HURTIGT svar. Sig til hvis vi skal oprette noget. Jeg kan se, at den oprindelige Bug #3113, der beskrev problemer med visning af fjernlån, er lukket og rettet? Vh Pernille W

#30 Updated by Simon Holt 11 months ago

  • Status changed from Development to Needs code review
  • Assignee changed from Simon Holt to Gitte Barlach

PR: https://github.com/ding2/ding2/pull/1293

Der viser sig at være nogle forskelle på hvordan systemet nu håndterer objekter, der ikke bliver fundet, og derfor er der begyndt at dukke så manglende titler op. Kan ikke helt genneskue om det er ændringer i SAL eller det faktum, at vi er gået over til getObject i flere situationer, der har gjort forskellen.

Mht. kollisioner id'er fra andre systemer, som vi diskuterede lidt i ovenstående, er der vel stadig teoretisk mulighed for sammenfald. Men sådan har det jo altid været, og den her rettelse fikser i det mindste de manglende title på statuslisterne.

Der er flere, der har omtalt dette problem inde på facebook også https://www.facebook.com/groups/ddbcms/permalink/821846851323639/, så ved ikke om den måske skal prioriteres lidt op?

#31 Updated by Simon Holt 11 months ago

  • Status changed from Needs code review to Development
  • Assignee changed from Gitte Barlach to Simon Holt

Jeg vil gerne lige kigge på denne igen, så har ændret status til "development".

PR i ovenstående er en lappeløsning på et mere generelt problem med at TingClientObjectRequest returnerer nogle "underlige" eller helt "tomme" objekter i visse tilfælde:

1. Hvis objekter ikke findes i brønden returneres de sådan her:

TingClientObject Object
(
    [id] => 0
    [data] => 
    [record] => Array
        (
            [dc:title] => Array
                (
                    [] => Array
                        (
                            [0] => Error: unknown/missing/inaccessible record: 0
                        )

                )

        )

    [relations] => Array
        (
        )

    [formatsAvailable] => Array
        (
            [0] => dkabm
        )

    [localId] => 
    [ownerId] => 0
)

Det betyder bl.a. fejlen i nærværende sag, men har ifb. med mit arbejde med #4041 fundet at det også giver warnings i opensearch_search_object_ids() fordi id'erne ikke er pid'er som forventet, men bare tal. F.eks. er id i ovenstående 0:

Notice: Undefined offset: 1 i opensearch_search_object_ids() (linje 613 af /var/www/drupalvm/drupal/web/profiles/ding2/modules/opensearch/includes/opensearch.search.inc).

2. Hvis TingClientObjectRequest ikke finder nogle objeker i søgeresultatet, returnerer den ikke et tomt array, men bare ingen ting (NULL). Dette resulterer i en fatal error i opensearch_get_objects() fordi den regner med at der returneres et array:

Error: Unsupported operand types i opensearch_get_objects() (linje 108 af /var/www/drupalvm/drupal/web/profiles/ding2/modules/opensearch/opensearch.client.inc)

Vi kunne selvfølgelig lappe til i ovenstående situationer ligesom det første PR i denne sag, ved at lave checks på det der returneres.

Jeg mener dog, at en meget bedre løsning er at få TingClientObjectRequest til at returnere noget der giver mening ved problematiske request:

- Hvis getObject returnerer fejlagtige objekter med titlen "Error: unknown/missing/inaccessible record: 0" skal de ikke returneres som objekter fra TingClientObjectRequest

- Hvis getObject ikke finder nogle objekter i søgeresultatet i processResponse() eller alle var unknown som i ovenstående, skal den ikke returnerer NULL, men et tomt array. Dette er meget mere i stil med andre API'er i Drupal (f.eks. entity_load()) og jeg synes også det giver mere mening.

 

 

#32 Updated by Simon Holt 11 months ago

  • Related to Bug #4041: Sletning af reservering udløser fejl added

#33 Updated by Rolf Madsen 11 months ago

  • Has duplicate Bug #4046: Error: unknown/missing/inaccessible record - Poster fra Det kongelige bibliotek - Aarhus added

#34 Updated by Simon Holt 11 months ago

  • Status changed from Development to Needs code review
  • Assignee changed from Simon Holt to Gitte Barlach

PR er opdateret:

https://github.com/ding2/ting-client/pull/27

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

Må dog indrømme jeg ikke er helt tilfreds med den måde vi agør om et objekt er en fejlmeddelelse, så hvis nogen har et bedre forslag er det velkommen :)

#35 Updated by Simon Holt 10 months ago

Den her kan godt merges og det vil fikse det alvorlige problem i denne sag lige her og nu. Men det er noget hacket lappeløsning. Ved nærmere eftertanke er det nok bedre at gå i dialog med DBC om bedre håndtering af ikke-fundne objekter og det der returneres.

Jeg har derfor oprettet en sag ved DBC og spurgt dem om følgende:

Jeg hjælper DDB med at løse et problem, der er forårsaget af den måde getObject håndtere request på objekter der ikke kan findes: https://platform.dandigbib.org/issues/3936

Det lader til at den returnerer en fejlmeddelelse som et rigtig objekt med en titel der starter med: "Error: unknown/missing/inaccessible record: ". Desværre narrer det DDB CMS til at vise disse objekter på lånernes statuslister, i stedet for at bruge oplysninger fra FBS API ved f.eks. fjernlån, der ikke eksisterer i brønden.

Jeg har forsøgt at fremsætte en løsning på problemet i sagen:
https://github.com/ding2/ting-client/pull/27
https://github.com/ding2/ding2/pull/1293

Men som det ses er det noget hacket, hvor vi checker om titlen på objektet har prefix "Error: unknown/missing/inaccessible record:". Jeg synes ikke det virker som den rigtige måde at håndtere det på.

Så jeg ville høre om vi kunne aftale en bedre måde at håndtere det på fra jeres side eller om I har nogle pointers til hvordan vi bedre kan håndtere den nuværende situation i DDB CMS.

Din sag har fået nummer: REQ0031374.

#36 Updated by Rolf Madsen 10 months ago

  • Related to Bug #4111: Mellemværende vedr fjernlån vises ikke korrekt i lånerstatus added

#37 Updated by Pernille Kirsten Wuttke 10 months ago

Simon Holt skrev:

Den her kan godt merges og det vil fikse det alvorlige problem i denne sag lige her og nu. Men det er noget hacket lappeløsning. Ved nærmere eftertanke er det nok bedre at gå i dialog med DBC om bedre håndtering af ikke-fundne objekter og det der returneres.

Jeg har derfor oprettet en sag ved DBC og spurgt dem om følgende:

Jeg hjælper DDB med at løse et problem, der er forårsaget af den måde getObject håndtere request på objekter der ikke kan findes: https://platform.dandigbib.org/issues/3936

Det lader til at den returnerer en fejlmeddelelse som et rigtig objekt med en titel der starter med: "Error: unknown/missing/inaccessible record: ". Desværre narrer det DDB CMS til at vise disse objekter på lånernes statuslister, i stedet for at bruge oplysninger fra FBS API ved f.eks. fjernlån, der ikke eksisterer i brønden.

Jeg har forsøgt at fremsætte en løsning på problemet i sagen:
https://github.com/ding2/ting-client/pull/27
https://github.com/ding2/ding2/pull/1293

Men som det ses er det noget hacket, hvor vi checker om titlen på objektet har prefix "Error: unknown/missing/inaccessible record:". Jeg synes ikke det virker som den rigtige måde at håndtere det på.

Så jeg ville høre om vi kunne aftale en bedre måde at håndtere det på fra jeres side eller om I har nogle pointers til hvordan vi bedre kan håndtere den nuværende situation i DDB CMS.

Din sag har fået nummer: REQ0031374.

Et enkelt spørgsmål: Betyder alt det her, at der primært/kun er fejl i visning af fjernlån fra Statsbiblioteket eller er det alle forskningsbibliotekerne? Og ved I hvorfor problemet er opstået ved netop sidste opdatering? Tidligere var det jo et andet og længere tid tilbage var der ingen problemer. Vh Pernille/Frederiksberg

 

#38 Updated by Simon Holt 10 months ago

Et enkelt spørgsmål: Betyder alt det her, at der primært/kun er fejl i visning af fjernlån fra Statsbiblioteket eller er det alle forskningsbibliotekerne? Og ved I hvorfor problemet er opstået ved netop sidste opdatering? Tidligere var det jo et andet og længere tid tilbage var der ingen problemer. Vh Pernille/Frederiksberg

Problemet opstår pga en fejl i opensearch, hvor den returnerer fejlmeddelelser som "rigtige" objekter (materialer). Dette narrer i dette tilfælde CMS til at prøve at vise disse objekter, hvilket resultere i et materiale med en fejlmeddelelse som titel. Grunden til at det pludselig begynder at opstå i CMS er fordi vi er gået over til en mere rigtig måde at hente materialer ned fra brønden via getObject, hvor denne fejl optræder.

Tror også det gælder forskningsbiblioteker. @Steen?

#39 Updated by Erik Bachmann 10 months ago

Problemet med fejlmeddelelser er meldt til DBC allerede i december:  REQ0026130 - getObject for DKABM returnere fejl i forkert format

Foreløbig har DBC ikke reageret. Har eskaleret sagen

#40 Updated by Simon Holt 10 months ago

Har selv haft kontakt med dem i forbindelse med dette her. De skriver:

Hej Simon

Jeg kan desværre ikke pt. sige noget sikkert om tidshorisonten for en løsning. Vi er ikke nået til den del i migreringsarbejdet endnu, så vi skal i hvert fald hen i 2. kvartal, inden der er en mulighed for at det er på plads.

 

#41 Updated by Pernille Kirsten Wuttke 10 months ago

Simon Holt skrev:

Har selv haft kontakt med dem i forbindelse med dette her. De skriver:

Hej Simon

Jeg kan desværre ikke pt. sige noget sikkert om tidshorisonten for en løsning. Vi er ikke nået til den del i migreringsarbejdet endnu, så vi skal i hvert fald hen i 2. kvartal, inden der er en mulighed for at det er på plads.

 

Tak for hurtigt svar. Vi ser virkelig frem til en løsning, som jeg håber DBC prioriterer højt, da det skaber forvirring og mange henvendelser fra lånerne. Sig til, hvis I har brug for flere eksempler. Vh Pernille Wuttke

#42 Updated by Erik Bachmann 10 months ago

Har svaret DBC følgende:

Som det er nu, kan klienten ikke detektere fejl, da fejlmeddelelsen indgår i den bibliografiske beskrivelse og ikke i feltet ”error”.

Dokumentationen er pt et enten-eller, som ikke tager højde for at en fejl kan berøre dele af et svar:

 

Parameter:

Always present:

Repeatable:

Sub element of:

Description:

error

if result is not present

no

searchResponse

Message returned by the service, if an error occurs.

result

if error is not present

no

searchResponse

The result from the service including searchResult, facets and statInfo.

 

Som jeg ser det, så SKAL fejl fremgå af “error”, men dette betyder ikke at ”result” ikke kan returneres – blot skal klienten så kunne håndtere evt. fejl.

Derfor vil jeg forelå at dokumentationen rettes til:

 

Parameter:

Always present:

Repeatable:

Sub element of:

Description:

error

On error

no

searchResponse

Message returned by the service, if an error occurs.

result

On full or partly searchResult

no

searchResponse

The result from the service including searchResult, facets and statInfo.

 

Servicen fortæller i eksemplet blot at posten ikke findes eller kan tilgås, men intet om evt. årsag. Den/de generelle meddelelser bør så optræde samlet i ”error”.

#43 Updated by Steen Larsen 10 months ago

@simon - ja, fejlen vil opstå ved alle fjernlånte materialer fra forskningsbiblioteker som der er regning/gebyr på.

I brønden er der namespace som er forskellige afhængig af om det er forskningsbibliotek eller folkebibliotek (hvor namespace er agencyid-katalog/870970-basis) men fra FBS får vi kun "faust" (ved regninger) og det er uden namespace, så de kan jo være fra hvad som helst.

Nogle gange kan vi se at det ikke er et faust (jvf regexp i tidligere note) - andre gange ligner det et faust - og måske er der så et hit med en reel post.

Men faktisk kan der vel udemærket være et sammenfald på id'ere, således at en låner som har gebyr på et fjernlån får vist et helt andet materiale - det må dog ske sjældent (gætter/håber jeg på).

 

#44 Updated by Gitte Barlach 9 months ago

  • Assignee changed from Gitte Barlach to Jørgen Nielsen

#45 Updated by Jørgen Nielsen 9 months ago

Jeg har en kommentar til https://github.com/ding2/ting-client/pull/27

Derudover: Er problemet i virkeligheden ikke, at FBS kun udleverer faust, og OpenSearch forventer en PID?
DDB-CMs "gætter" så på, at PID'en er 870970-basis:xxxxxxxx, og det fejler.
Men Cicero får PID'en udleveret ifm. fjernlånsbestillinger, så det burde være et spørgsmål om at få Cicero til at gemme PID'en - og udlevere den igen...

#46 Updated by Jørgen Nielsen 9 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jørgen Nielsen to Simon Holt

#47 Updated by Simon Holt 9 months ago

@Jørgen Nej, det er ikke helt det der er problemet. Vi kan sagtens oversætte faust til pid med: https://github.com/ding2/ding2/blob/master/modules/opensearch/includes/opensearch.search.inc#L608 

Problemet er, at nogle fjernlån fra bl.a. forskningsbiblioteker slet ikke kan søge/hentes fra opensearch. Så vidt jeg kan forstå på Steen, er det i nogle tilfælde slet ikke et faust, der er tale om.

Problemet er, at opensearch getObject returnerer fejlen med at den ikke kan finde noget som et rigtig objekt, og det narrer så DDB CMS til at tro at den har fundet et materiale.

Vi har været i kontakt med DBC om en bedre måde at håndtere det på. Indtil videre er planen vist at det skal returneres som:

<searchResult>
  <collection>
    <resultPosition>2</resultPosition>
    <numberOfObjects>1</numberOfObjects>
    <object>
      <error>unknown/missing/inaccessible record: 870970-basis:98540167</error>
      <identifier>870970-basis:98540167</identifier>
    </object>
  </collection>
</searchResult>

 

Så vi får en error, som vi forhåbentlig kan håndtere meget bedre i CMS.

 

Så vidt jeg forstår, er vi ved at finde ud af om der kan laves en ny version af opensearch så vi kan teste det, før vi går i produktion med det.

 

Så denne sag bør vel egentlig sættes til "development". Beklager, skulle have tænkt på det noget før.

 

#48 Updated by Simon Holt 9 months ago

  • Status changed from Reviewed - Needs info/rework to Development

#49 Updated by Steen Larsen 9 months ago

Ved reserveringer / lån udleveres oplysninger om titel/forfatter når der er tale om fjernlån - det sker ikke ved regninger og det er nok egentlig det som er fejlen.

Som et workaround gætter vi på det jo nok er et faust, søger og ser hvad der sker - og kommer der et svar er det forhåbentlig godt nok. Det synes jeg egentlig ikke er den rigtige vej at gå, men måske den bedst mulige pt?

#50 Updated by Simon Holt 9 months ago

Ved reserveringer / lån udleveres oplysninger om titel/forfatter når der er tale om fjernlån - det sker ikke ved regninger og det er nok egentlig det som er fejlen.

Det der er fejlen i denne sag i hvert fald er, at CMS ikke bruger oplsyningerne fra FBS API, fordi den narres til at tro, at der blev fundet et objekt, som i virkeligheden er en fejl. Der var ikke et problem før vi gik over til getObject, da en rec.id søgning ikke returnerer noget, hvis den ikke finder noget.

Det med at vi ved nogle fjernlån slet ikke kan vise noget ved mellemværende kan da helt sikkert også betragtes som en fejl, men sådan har det jo altid været, også før problemet i denne sag opstod og sagen blev oprettet.

Som et workaround gætter vi på det jo nok er et faust, søger og ser hvad der sker - og kommer der et svar er det forhåbentlig godt nok. Det synes jeg egentlig ikke er den rigtige vej at gå, men måske den bedst mulige pt?

Hvis vi kan finde en pålidelig måde at afgøre om et id er et faust, vil det være en vej at gå. Kan vi ikke det, har jeg svært ved at se hvad vi ellers skal gøre.

Men Cicero får PID'en udleveret ifm. fjernlånsbestillinger, så det burde være et spørgsmål om at få Cicero til at gemme PID'en - og udlevere den igen...

Det lyder interresant. Men det er jo ikke kun ifb med fjernlånsbestillinger, at vi har behov for at finde det korrekte PID. Ved almindelig lån/bestillinger står vi også kun med et faust, og her vil vi gerne bestemme det korrekte namespace, så vi kan vise de korrekte informationer om materialet.

#51 Updated by Steen Larsen 9 months ago

Ok, så har jeg vist misforstået sagen.

Men oplysningerne som FBS API leverer i ilBibliographicRecord for fjernlån og -reserveringer skal vi vel bruge og brønden skal slet ikke spørges her?
Er lånet (loanType=interLibraryLoan) så kan/vil feltet recordId indeholde noget andet end Faust og vi har jo ikke namespace så vi præcist kan finde posten.

#52 Updated by Simon Holt 9 months ago

Men oplysningerne som FBS API leverer i ilBibliographicRecord for fjernlån og -reserveringer skal vi vel bruge og brønden skal slet ikke spørges her?

Det ville være en mulig løsning, at vi tjekkede om ilBibliographicRecord var til stede og så udelukkende brugte informationerne fra FBS API i disse tilfælde og helt lader være med at spørge brønden. Men så må vi også opgive at linke til visning af materialerne og forside for de fjernlånsmaterialer som rent faktisk kan findes i brønden. Hvis vi skal det, er vi nødt til vide om det eksisterer i brønden.

Er lånet (loanType=interLibraryLoan) så kan/vil feltet recordId indeholde noget andet end Faust og vi har jo ikke namespace så vi præcist kan finde posten.

Nøgleordet her er vist kan. Det vil vel ikke nødvendigvis?

#53 Updated by Jørgen Nielsen 9 months ago

@Simon Holt:

Problemet er, at nogle fjernlån fra bl.a. forskningsbiblioteker slet ikke kan søge/hentes fra opensearch. Så vidt jeg kan forstå på Steen, er det i nogle tilfælde slet ikke et faust, der er tale om.

Min påstand er, at man KAN hente posterne fra opensearch. Men det kræver, at man søger på den korrekte PID (F.ex. 820010-katalog:2789829). Det er også muligt, at man skal søge med en anden søgeprofil - afgrænses søgningen til bibliotekets bestand, kan man naturligvis ikke finde posten. Rent konkret, så skal man ha' kilden "Forskningsbiblioteker til danbib" med i profilen.

Prøver man at danne en PID ved at sætte lokalId sammen med '870970-basis:', f.ex.: 870970-basis:2789829 fejler søgningen sandsynligvis. 
Og laver man en searchRequest i stedet for en getObjectRequest, og søger på lokalId, vil man måske, måske ikke få et hit. Muligvis vil man få mere end ét hit. LokalId er nemlig ikke unikt, og kan være brugt på flere biblioteker, på forskellige værker.

#54 Updated by Simon Holt 9 months ago

@Jørgen tak for input. Har lige et par kommentarer/ting der skal afklares til det du skriver.

Min påstand er, at man KAN hente posterne fra opensearch. Men det kræver, at man søger på den korrekte PID (F.ex. 820010-katalog:2789829). Det er også muligt, at man skal søge med en anden søgeprofil - afgrænses søgningen til bibliotekets bestand, kan man naturligvis ikke finde posten. Rent konkret, så skal man ha' kilden "Forskningsbiblioteker til danbib" med i profilen.

Det med "Forskningsbiblioteker til danbib" er nyt for mig. Men jeg har svært ved at se hvordan denne information ændrer situationen. DDB CMS bør, efter min mening, ikke lave antagelser om hvilken VIP-profil det pågældende bibliotek benytter og hvad der er slået til/ikke slået til i den. Faktum er, at det for CMS i nogle tilfælde ikke er muligt at hente posten, som alle rapporteringerne om denne fejl vidner om. Det bliver vi nødt til at forholde os til og håndtere i CMS.

Prøver man at danne en PID ved at sætte lokalId sammen med '870970-basis:', f.ex.: 870970-basis:2789829 fejler søgningen sandsynligvis. 

Jamen i de tilfælde hvor det sker, har vi jo ikke så mange andre valg. Vi har prøvet at slå faust/lokalid op med getObject og vi får ikke noget. Det bedste vi kan gøre er at prøve at lave et opslag på basis-namespace for at se om det giver noget.


Og laver man en searchRequest i stedet for en getObjectRequest, og søger på lokalId, vil man måske, måske ikke få et hit. Muligvis vil man få mere end ét hit. LokalId er nemlig ikke unikt, og kan være brugt på flere biblioteker, på forskellige værker.

Ok, nu står jeg helt af. Så det du siger er, at fauts-numre ikke er unikke indenfor bibliotekskataloget? Hvis det er tilfældet, skal vi have fundet en helt anden måde at gribe det an på. Og det er ikke et search request vi laver længere, men et getObject request, da den nu understøtter opslag på flere objekter ad gangen. Historikken er:

1. I #2048 blev det opdaget, at der for nogle poster blev vist forkert information på statuslisterne. Årsagen var, at der blev brugt det forkerte namespace. For poster indenfor bibliotekeskataloget kan det enten være 870970-basis:FAUST eller AGENCYID-katalog:FAUST. Så vi lavede en løsning hvor der blevet lavet en rec.id søgning på de lokalid'er vi fik udleveret fra FBS API. Søgninger der blev lavet var:

'rec.id any "' . implode(" ", $ids) . '" AND facet.acSource=bibliotekskatalog';

Bemærk at vi afgrænser til bibliotekskataloget med den overbevisning at lokal id'erne er unikke indenfor denne kilde.

2. I #3828 blev funktionen omskrevet til at bruge et getObject request med lokalId'er istedet, da der var problemer med at de værker der blev returneret fra ovenstående søgning blev lagt i cachen som enkelt-post værker og dermed opstod problemet "Værkmatch har hukommelse (i dette tilfælde. Der er andre tilfælde hvor det kan opstå)". Desuden virkede det også mere korrekt at bruge getObject.

Men nu kommer jeg helt i tvivl om det var det rigtige at gøre, med det du skriver.

- Først og fremmest er det ikke korrekt at lokal id'er/faust (whatever) er unikke indenfor bibliotekskataloget?

- Og er localIdentifier i getObject ikke bare faust men lokalid på alle kilder? 

Bemærk at vi i getObject request jo ikke har den samme afgrænsning på bibliotekskatalog, som vi havde i søgning, hvilket måske kan give problemer med sammenfald i andre kilder? Hvis det er tilfældet, bliver vi nødt til at finde en anden løsning eller gå tilbage til en rec.id søgning og få det til at fungere.

Under alle omstændigheder er vi nok lidt på afveje her ift det oprindelige problem i denne sag, der går ud på, at vi skal kunne håndtere at opensearch ikke returnerer noget for et PID på en fornuftig måde.

 

#55 Updated by Steen Larsen 9 months ago

Man skal huske at FBS kalder alle id-numre for faust uanset om det er en folkebibliotekspost (korrekt) eller om det er en fjernlånspost (ikke altid korrekt).

Er posten fra forskningsbibliotekerne er det ikke faust og dét id (altså uden namespace) kan være brugt på forskellige værker på forskellige biblioteker.

#56 Updated by Simon Holt 9 months ago

Ok, hvis vi lige skal skære det ud i pap, vil det sige at:

1. Hvis posten ikke er et fjernlån er den fra bibliotekskataloget og vi kan regne med at det lokale id/faust vi har modtaget fra FBS API er unikt indenfor bibliotekskataloget. Vi kan derfor tillade os slå dette faust op i getObject via localIdentifier og dermed finde det korrekte namespace.

2. Hvis posten er et fjernlån kan det ID vi modtager fra FBS API være brugt på forskellige værker. Det kan godt være det er et "faust" fra et andet folkebibliotek, men vi kan ikke være sikker og slår vi det op for at finde namespace, er det chance for sammenfald.

Så hvis det her skal være helt skudsikkert, ser jeg ikke andre muligheder, end at vi kun prøver at finde namespace hvis ILLBibliographicRecord ikke er til stede. Hvis den er til stede, må vi opgive at linke til postens materialevisning og i stedet udelukkende bruge de oplysninger vi modtager fra FBS API ved alle fjernlån. Hvis vi ikke kan være sikker på id er unikt, kan vi ikke bruge metoden til at slå op i getObject for at finde namespace. Hvis posten er fra forksningsbibliotekerne risikerer vi at ramme et faust på en folkebibliotekspost. Hvis posten er fra et folkebibliotek risikerer vi at ramme en fra forksningsbiblioteker. Eksempelvis.

Det er stadig vigtigt at vi her får løst problematikken med "fejlsvar som rigtige objekter", men måske kunne vi i samme omgang lave ovenstående.

Så vi opgiver links til materialevisning for fjernlånsposter helt og prøver kun at finde namespace når posten ikke er et fjernlån. Umiddelbart kan vi så heller ikke vises covers, da det er lidt flettet ind i det her med at slå op i opensearch. Det kunne dog laves, men det er ikke noget, der vil virke umiddelbart.

Hvis FBS API kunne udvides til at sende det PID med, den har fået fra fjernlånet, i ILLBibliographicRecord, som Jørgen foreslåer i #note-45, kunne vi i disse tilfælde prøve at slå dette PID op i opensearch for at se om vi kan linke til materialevisningen/vise flere informationer.

#57 Updated by Gitte Barlach 9 months ago

jeg vil lige sige at problemstillingen gælder fjernlån - både fjernlån og fjernlånsreserveringer. Dvs brugeren oplever fejlen i oversigterne :

/user/me/status-reservations
/user/me/status-loans

Det har vi her i Aarhus fået flere brugerhenvendelser omkring (se skærmdumps)

Med den løsning der er på vej skal vi også sikre korrekt visning i:

/user/me/status-loans-overdue
/user/me/status-reservations-ready
/user/me/status-debts

#58 Updated by Simon Holt 9 months ago

@Gitte jeps, det er korrekt. Vil også mene mellemværende listen kan være berørt, hvis vi prøver at slå lokale id'er op fra for mellemværende ifb med fjernlån.

#59 Updated by Gitte Barlach 9 months ago

  • Priority changed from Normal to High

vi får stadigvæk jævnligt henvendelser på denne fejl. Vi kan evt. godt løse den her i Aarhus og sende et PR tilbage ? medmindre du har noget på vej, Simon ?

#60 Updated by Gitte Barlach 9 months ago

  • Subject changed from reserveringsvisning af fjernlån to Visning af fjernlån i lånerstatus (reserveringer og lån) fejler og giver "Error: missing/unknown/inaccessible record..."

#61 Updated by Simon Holt 9 months ago

@Gitte Der er faktisk allerede postet en midlertidig løsning i https://platform.dandigbib.org/issues/3936#note-34.

Og jeg ville egentlig have ventet med at lave noget, til DBC havde et miljø klar, hvor kunne teste deres rettelse med bedre håndtering af fejlsvar.

Men kan egentlig godt se, at den løsning jeg foreslår i #note-56, hvor vi udelukkende benytter oplysninger fra FBS API for fjernlån, faktisk burde løse problematikken her helt.

Men vi skal ikke glemme at tilpasse vores kode i CMS, når DBC har rettet fejlen med fejlsvar som rigtige objekter. Vi skal simpelthen kunne håndtere opslag på objekter der ikke kan finde i opensearch på en ordentlig måde.

Så jeg foreslår vi opretter en ny sag, der omhandler tilpasning/test af CMS til DBC's opdaterede fejlhåndtering på getObject.

Og jeg laver et nyt PR ASAP med fremgangsmåden beskrevet i #note-56, så vi kan få denne sag løst hurtigst muligt.

#62 Updated by Steen Larsen 9 months ago

Vær lige opmærksom på at ved mellemværende udleverer FBS API ikke oplysningerne om titel, forfatter m.m. dvs der er ikke noget "hint" om at der er tale om fjernlån

 

#63 Updated by Simon Holt 9 months ago

@Steen Ja, den har naget mig lidt.

Har overvejet om man kunne tage det ID vi får udleveret fra FBS API og prøve at lave et request med basis namespace og katalog namespace og se hvad der returneres. Hvis der er en katalog post bruger vi den ellers bruger vi basis posten. Hvis der ikke returneres noget er posten vel højst sandsynligt et fjernlån og så må vi i disse tilfælde skrive at vi ikke kan vise titlen.

Vil det være holdbart?

#64 Updated by Simon Holt 9 months ago

Jeg har spurgt Martin Christensen fra Redia om hvordan de håndterer dette i app'en.

De gør ligesom vi gjorde før i tiden med at lave en rec.id-søgning på faust, men går snart over til getObject ligesom vi gør nu.

De søger også på fjernlån, men er nu blevet gjort opmærksom på, at det nok ikke er så smart pga mulighed for sammenfald.

De står også med problemet med mellemværender, hvor det ikker er muligt at afgøre om det er fjernlån og der ikke returneres noget metadata.

#65 Updated by Gitte Barlach 9 months ago

Jeg vil gerne foreslå vi deler denne her op i to, for at vi kan komme videre:

a) i nærværende sag, 3936, fixer vi oversigterne over lån og reserveringer
 

@Simon: jeg går ud fra at de to PRs du kommer med i kommentar 34, løser dette?

https://github.com/ding2/ting-client/pull/27

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

b) i en *ny sag*, vi opretter, adresserer vi problematikken omkring mellemværender; dette kræver jo involvering fra Systematic, og kan derfor vise sig at tage meget lang tid at løse. 

#66 Updated by Gitte Barlach 9 months ago

Jeg korrigerer lige mig selv, efter at have talt med Simon:

Vi deler sagen op i tre. for at komme videre:

a) i nærværende sag, 3936, fixer vi oversigterne over lån og reserveringer
Simon laver et nyt PR ASAP med fremgangsmåden beskrevet i #note-56, så vi kan få denne sag løst hurtigst muligt.

Og vi opretter 2 nye sager:

b) en sag, hvor vi adresserer vi problematikken omkring mellemværender; dette kræver jo involvering fra Systematic. Simon opretter et udviklingsønske til KOMBIT så FBS API i fremtiden kan udlevere info. om et lån er et fjernlån
Har nu oprettet #4208

c) en sag, hvor vi behandler problematikken om at opensearch getObject returnerer fejlen med at den ikke kan finde noget som et rigtig objekt, og det narrer så DDB CMS til at tro at den har fundet et materiale. DBC arbejder på at rette dette. Så sagen ift. DDB cMS omhandler tilpasning/test af CMS til DBC's opdaterede fejlhåndtering på getObject, når den altså foreligger.

#67 Updated by Simon Holt 9 months ago

  • Status changed from Development to Needs code review
  • Assignee changed from Simon Holt to Gitte Barlach

Så er der PR der, efter aftale med Gitte, fikser på problemet på lån/reservations statuslisterne: https://github.com/ding2/ding2/pull/1384.

Fandt og fiksede en lidt underlig urelateret fejl, der så ud til gå meget ud over performance. Så måske vil dette PR også give lidt bedre performance på statuslisterne. Men det er meget teknisk og har skrevet mere om det i PR og commit messages.

#68 Updated by Gitte Barlach 9 months ago

  • Assignee changed from Gitte Barlach to Jesper Kristensen

#69 Updated by Simon Holt 9 months ago

  • Related to Bug #4212: Opensearch getObject returnerer fejlsvar som rigtige objekter added

#70 Updated by Simon Holt 9 months ago

Oprettet ny sag om "getObject returnerer fejlsvar som rigtige objekter": #4212

#71 Updated by Jesper Kristensen 8 months ago

Hej Simon

Jeg skal lige være helt med... dette PR laver status lister om til altid/kun at bruge information fra FBS/provider og aldrig lave opsalg i brønden til disse lister og ikke kun ved ILL.

Er det rigtig forstået?

#72 Updated by Jesper Kristensen 8 months ago

  • Status changed from Needs code review to Need more info

#73 Updated by Simon Holt 8 months ago

Hej Jesper

Nej, det laver det om til altid at bruge data fra FBS API ved ILL lån/reserveringer. Ved almindelige lån/reserveringer virker det ligesom før.

Før tjekkede vi brønden hver gang uanset ILL (og nogle gange sendte vi et forkert ding_entity_id fra provideren). Nu kan provideren selv afgøre om ding_loan/reservation skal tjekke søge provideren ved at sende/ikke sende et ding_entity_id.

 

#74 Updated by Simon Holt 8 months ago

  • Status changed from Need more info to Needs code review

#76 Updated by Simon Holt 8 months ago

Men fjerner du ikke kald til brønden her: https://github.com/ding2/ding2/pull/1384/files#diff-6023214c29e0026da2b604ef2d5703aeL182 

Jo, jeg fjerner det kald til fordel for at bruge getEntity() metoden på DingProviderReservation og DingProviderLoan. Når man kalder ->entity på en af de klasser bliver man via magic getter redicrected til getEntity(), som loader entitien via ding_entity_load()

Det der faktisk er lidt underligt i den kode du linker til er, at man allerede har prøvet at loade entity engang (ved kaldet til $loan->entity) og det gik ikke godt og så prøver man igen at loade den via ding_entity_id. Det er i praksis det samme der gøres to gange. Jeg har bare ryddet lidt op i koden :)

og jeg ser da ingen check i https://github.com/ding2/ding2/blob/a0a4ae133c1fc31ce38a0e7f9ffa62fbb224d6cb/modules/ding_loan/plugins/content_types/loans.inc#L173 efter om det er ILL?

Eftersom det her er MEGET provider specifikt, har jeg valgt at håndtere det i FBS modulet. Så det er FBS der tjekker om der er ILL-data her: https://github.com/ding2/ding2/pull/1384/files#diff-f64beeaa5c9b72d3dd0348e2b3567642R59&nbsp;

#77 Updated by Jesper Kristensen 8 months ago

Okay, så er jeg osse helt med :-)

#78 Updated by Jesper Kristensen 8 months ago

  • Status changed from Needs code review to Reviewed
  • Assignee changed from Jesper Kristensen to Gitte Barlach

Reviewed og afventer release (https://github.com/ding2/ding2/pull/1384)

#79 Updated by Simon Holt 8 months ago

Faldt over en Fatal: "Call to a member function getId() on null" som ændringen i denne sag har medført i Webtrekk modulet.

Har derfor opdateret PR med en rettelse og sat til "Needs code review" igen.

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

#80 Updated by Simon Holt 8 months ago

  • Status changed from Reviewed to Needs code review

#81 Updated by Gitte Barlach 8 months ago

  • Assignee changed from Gitte Barlach to Jørgen Nielsen

#82 Updated by Pernille Kirsten Wuttke 7 months ago

Simon Holt skrev:

Faldt over en Fatal: "Call to a member function getId() on null" som ændringen i denne sag har medført i Webtrekk modulet.

Har derfor opdateret PR med en rettelse og sat til "Needs code review" igen.

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

 

Hej.

Som I ved, fejler det fortsat og vi får en del henvendelser på det, hvorfor vi glæder os til en løsning. Men sjovt nok vises samme fjernlånstitler korrekt i BIBLIOTEKET-app'en, og da der jo arbejdes på en vis synergi mellem CMS og APP, tænkte jeg, om I måske kunne finde en løsning ad den vej?

God påske. Vh Pernille W

#83 Updated by Jørgen Nielsen 7 months ago

  • Status changed from Needs code review to Reviewed - Needs info/rework
  • Assignee changed from Jørgen Nielsen to Simon Holt

Jeg har en enkelt kommentar...

#84 Updated by Jakob Luther 7 months ago

Hej

Jeg kan ikke gennemskue om dette kun drejer sig om fjernlånte materialer, men vi (Esbjerg) oplever samme fejl på lokalposter..

Når man laver en reservering/låner f.eks. en læsekasse (katalogiseret som lokalpost) er titlen i lånerstatus Error: unknown/missing osv. som de eksempler der er på fjernlån.

Hvis lokalposter er indkluderet i ovenstående er det bare mig der ikke har fanget det.

Med venlig hilsen

Jakob

 

#85 Updated by Steen Larsen 7 months ago

Nej, fejl med lokalposter tror jeg ikke er relateret til det her, så her bør du lave en ny sag med dokumentation (url/faust)

Vær opmærksom på at i ddbcms f.eks. kan man udelade visse filialer fra søgning ( /admin/config/ding/provider/fbs - search branches blacklist) så materialer som kun findes dér kan ikke søges frem og vises, men materialerne kan jo selvfølgelig i Cicero stadig reserveres til en konkret låner. Og visning i lånerstatus efterfølgende kunne måske give problemer.

#86 Updated by Simon Holt 7 months ago

  • Status changed from Reviewed - Needs info/rework to Needs code review
  • Assignee changed from Simon Holt to Jørgen Nielsen

@Jørgen har svaret på kommentar på Github.

#87 Updated by Jørgen Nielsen 7 months ago

  • Assignee changed from Jørgen Nielsen to Simon Holt

@Simon: og svaret dér :-)

#88 Updated by Simon Holt 7 months ago

  • Assignee changed from Simon Holt to Gitte Barlach

#89 Updated by Simon Holt 7 months ago

PR er opdateret og alt er grønt nu :D

#90 Updated by Gitte Barlach 7 months ago

  • Assignee changed from Gitte Barlach to Jørgen Nielsen

kan du godkende, Jørgen ?

#91 Updated by Jørgen Nielsen 7 months ago

  • Assignee changed from Jørgen Nielsen to Gitte Barlach

reviewet og godkendt :-)

#92 Updated by Jørgen Nielsen 7 months ago

  • Status changed from Needs code review to Reviewed

#93 Updated by Jakob Luther 7 months ago

Steen Larsen skrev:

Nej, fejl med lokalposter tror jeg ikke er relateret til det her, så her bør du lave en ny sag med dokumentation (url/faust)

Vær opmærksom på at i ddbcms f.eks. kan man udelade visse filialer fra søgning ( /admin/config/ding/provider/fbs - search branches blacklist) så materialer som kun findes dér kan ikke søges frem og vises, men materialerne kan jo selvfølgelig i Cicero stadig reserveres til en konkret låner. Og visning i lånerstatus efterfølgende kunne måske give problemer.

mystisk mit svar på denne er blevet afvist... Så det kommer lige igen.

 

Fint – jeg laver en ny sag på det… Men det har ikke noget med blacklist af branch eller andet at gøre. Læsekasser står på Hovedbiblioteket eneste forskel er at de har et andet faustnr og ikke kan søges i brønden af andre biblioteket.

 

Mener også at kunne huske at lokalposter i andre tilfælde ”opførte” sig som de fjernlånsposter der har visningsproblemer.

 

#94 Updated by Simon Holt 7 months ago

Er næsten 100% sikker på at rettelsen fra #4194 vil løse problemet med visning af lokalposter. Den retter en fejl som gør at vi bruger basis namespace for alle poster på lånestatus og derfor passer det godt med, at der er problemer med lokalposter, da disse jo netop ikke kan søges via basis.

@Gitte

Hvis I tester denne uden rettelsen fra #4194 skal I derfor være opmærksom på, at der stadig kan være fejlvisning på lokalposter, selvom rettelsen i sagen her løser problemet for fjernlånsposter.

#95 Updated by Pernille Kirsten Wuttke 7 months ago

Simon Holt skrev:

Er næsten 100% sikker på at rettelsen fra #4194 vil løse problemet med visning af lokalposter. Den retter en fejl som gør at vi bruger basis namespace for alle poster på lånestatus og derfor passer det godt med, at der er problemer med lokalposter, da disse jo netop ikke kan søges via basis.

@Gitte

Hvis I tester denne uden rettelsen fra #4194 skal I derfor være opmærksom på, at der stadig kan være fejlvisning på lokalposter, selvom rettelsen i sagen her løser problemet for fjernlånsposter.

Hej

Som tidligere nævnt blev fejlen rettet på app'en med Release 2.3.1 (november, 2018) - mon I kan finde en løsning der? Vh P

 

#96 Updated by Kasper Garnæs 6 months ago

  • Status changed from Reviewed to Technical test
  • Assignee changed from Gitte Barlach to Kasper Garnæs

#97 Updated by Kasper Garnæs 6 months ago

  • Assignee changed from Kasper Garnæs to Gitte Barlach

#98 Updated by Tue Gaston 6 months ago

  • Assignee changed from Gitte Barlach to Tue Gaston

#99 Updated by Tue Gaston 5 months ago

Testet og godkendt.
grevebib.dk venstre og upgrade til højre:

#100 Updated by Tue Gaston 5 months ago

  • Status changed from Technical test to Resolved (tag version)
  • Assignee changed from Tue Gaston to Gitte Barlach

#101 Updated by Melissa Wieser 5 months ago

 

Vi har opgraderet i Allerød (redaktør) og vi har fortsat problemet med fjernlån fra fag- og forskningsbiblioteker. Titlerne vises rigtigt i vores app  og i lånerstatus i bibliotek.dk, men vises fortsat forkert på hjemmesiden.
Herudover oplever vi problemer med flere af de tekster, vi tidligere har kunnet oversætte - f.eks. netop strengen  "unknown/missing/inaccessible record" som vi har ændret til "Titel kan ikke vises - se evt. din lånerstatus i bibliotek.dk eller app'en Biblioteket" Det har tidligere virket - men vises ikke længere. (Vi har ændret den her: /admin/config/regional/translate/edit/20627?destination=admin/config/regional/translate/translate )

Men vi vil nu helst have at fjernlånstitlerne skal vises korrekt. Er der en tip til opsætning, som vi måske mangler?

 

Tue Gaston skrev:

Testet og godkendt.
grevebib.dk venstre og upgrade til højre:
 

#102 Updated by Gitte Barlach 5 months ago

Jeg har oprettet en ny sag som vi kan fortsætte i: #4413

#103 Updated by Tue Gaston 5 months ago

  • Related to Bug #4413: Fjernlån fra fag- og forskningsbiblioteker giver fortsat "unknown/missing/inaccessible record" added

#104 Updated by Rolf Madsen 2 months ago

  • Related to Bug #4512: Opgrader til https://opensearch.addi.dk/b3.5_5.2/ added

#105 Updated by Rolf Madsen 2 months ago

  • Subject changed from Visning af fjernlån i lånerstatus (reserveringer og lån) fejler og giver "Error: missing/unknown/inaccessible record..." to Visning af fjernlån i lånerstatus (reserveringer og lån) fejler og giver "Error: missing/unknown/inaccessible record..." LØSES MED #4512

Also available in: Atom PDF