Projekt

Generelt

Profil

Bug #1460

Reserveringsknap på årbøger giver problemer

Tilføjet af Tina Skjærbæk Søeborg for mere end 3 år siden. Opdateret for en dag siden.

Status:
Reviewed
Prioritet:
High
Tildelt til:
Anslået tid:
URL med eksempel:
Kategorier:
Inspiration - Forsiden, Søgning - Materialevisning

Beskrivelse

Der er et problem med reserveringsknapper på årbøger, som er en speciel variant af fænomenet med reserveringsknap på tidsskrifter og periodika

Sagen er, at nogle årbøger har årgangen og numre, andre har det ikke.

Hvis man aktiverer reserveringsknappen for årbøger, vises knappen på hovedposten uanset om materialet har årgange og numre. Hvis en låner klikker på knappen, får de en fejlmeddelelse "Only library user can make reservations."

Se fx https://hvidovre-stg.ddbcms.dk/ting/object/870970-basis%3A51174275

Hvis man derimod fjerner hak i reserveringsknap for årbøger, fjernes knappen på hovedposten på ALLE årbøger, også dem der ikke har årgange og numre. For deres vedkommende betyder det så, at de slet ikke kan reserveres.

Sådan har vi sat det op på vores produktionsmiljø for at undgå ovenstående fejl.
Se fx https://www.hvidovrebib.dk/ting/object/870970-basis%3A51837231

Der er altså behov for at finde en løsning, så reserveringsknappen vises på hovedposten, hvis der ikke er årgange eller numre, og vises på de enkelte årgange/numre, hvis der er det.


Relaterede sager

relaterer til DDB CMS - Bug #2530: Problemer med reservering af tidsskrifterResolved (tag version)
relaterer til DDB CMS - Enhancement #3325: Abstraktion af materialetyper for tidsskrifterResolved (tag version)
duplikater DDB CMS - Bug #1545: Visse periodikum kan ikke reserveresClosed

Historik

#1 Opdateret af Rolf Madsen for mere end 3 år siden

  • Status ændret fra New til Open (waiting)
  • Prioritet ændret fra Normal til Urgent
  • Udgave sat til DDB CMS 2016 1. opgradering

#2 Opdateret af Tina Skjærbæk Søeborg for mere end 3 år siden

Min beskrivelse ovenfor af scenariet med reserveringsknap på hovdposten er ikke helt korrekt.

Fejlmeddelelse "Only library user can make reservations." skyldtes, at jeg var logget ind som webmaster, da jeg forsøgte at lave reservationen.

Problemet eksisterer som beskrevet, men hvis man klikker på reserver-knappen på en årbogs hovedpost får man teksten "[xxx] kan ikke reserveres."

Så fejlmeddelelsen er altså mere meningsfuld, en jeg først skrev, men den betyder stadig, at folk ikke opdager, at de ville kunne reservere indiduelle årgange, hvis de klappede niveauerne ud.

Det angivne eksempel var heller ikke en god illustration, da den kun har en årgang, der dog er oprettet som årgang (3. variant), så den kunne man resevere.

Et bedre eksempel er denne, hvor der er flere årgange og man får fejlmeddelelsen:
https://hvidovre-stg.ddbcms.dk/ting/object/716700-katalog%3A90196049

#4 Opdateret af Rolf Madsen for mere end 3 år siden

  • Udgave ændret fra DDB CMS 2016 1. opgradering til DDB CMS - Analyse og prioritering udestår

#5 Opdateret af Rolf Madsen for cirka 2 år siden

  • duplikater Bug #1545: Visse periodikum kan ikke reserveres tilføjet

#6 Opdateret af Rolf Madsen for cirka 2 år siden

  • Prioritet ændret fra Urgent til None
  • Kategorier Søgning - Materialevisning tilføjet

Hej Tina.

Jeg har vurderet at Steens beskrivelse på #1545 er mere udfoldet og jeg vil derfor lukke dette issue.

Hvis der er pointer i dette issue som du mener Steen har overset vil du så ikke overføre dem?

På forhånd tak!!

#7 Opdateret af Tina Skjærbæk Søeborg for cirka 2 år siden

Hej Rolf

Jeg mener ikke, det er samme problem. Steen beskriver, at der er noget uoverensstemmelse mellem typen i dkabm-posten og marc-posten, som giver problemer for periodika.

Problemet for årbøger er ikke, at typen nogle gange er forkert. Problemet er, at der er årbøger både med og uden årgange og numre. For at kunne reservere de enkelte årgange for de materialers vedkommen, der har årgange, er man nødt til at fjerne hakket i "provider availability holdings", så der ikke kommer en reserver knap på hovedposten.
Men det betyder så for de årbøger, der IKKE har årgange og numre, slet ikke har nogen reserveringsknap, selvom de burde kunne reserveres, og det er jo ærgerligt.

Periodika vil altid have numre, så for deres vedkommende er det ikke noget problem.

#8 Opdateret af Rolf Madsen for cirka 2 år siden

  • Status ændret fra Open (waiting) til Needs analysis
  • Prioritet ændret fra None til High
  • Udgave ændret fra DDB CMS - Analyse og prioritering udestår til Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)

Jeg kan godt se hvad du siger.

Så grundlæggende kan vi ikke nøjes med at tjekke availability før vi indsætter Reservér knappen.

Vi er nødt til at tjekke beholdningen, og hvis årgang/nummer:

  1. findes på posten skal Reservér knappen IKKE vises på posten, men ud for hver årgang/nummer visning som vi er vant på tidsskrifter
  2. IKKE findes på posten skal Reservér knappen vises på posten som vi er vant til fra bøger og andre materialer end tidsskrifterne.

#9 Opdateret af Rolf Madsen for cirka 2 år siden

  • Tildelt til sat til Tina Skjærbæk Søeborg

#10 Opdateret af Tina Skjærbæk Søeborg for cirka 2 år siden

Lige præcis - og så i øvrigt kommunikere ud til alle os, der har slået knappen fra lige nu pga. fejlen, at vi skal slå den til igen :)

#11 Opdateret af Steen Larsen for cirka 2 år siden

Jeg har ikke checket hvordan sagen er med FBS og brønd 3.5 - mine gamle kommentarer i #1545 går på Alma og brønd 3.0
Meget af min kommentar dér går på at dkabm-posten ikke altid giver et godt bud på om knappen skal vises på den ene eller anden måde.

Måske skal vi simpelthen droppe dkabm-posten og udelukkende se på hvad provideren giver - som jeg skriver:
"Der bør kigges på om visning af beholdningsoplysningerne udelukkende baseres på provider-oplysningerne istedet for også at afhænge af hvad dkabm-posten leverer"

Dvs uanset hvad dkabm-posten fortæller (og som vi viser i titler, beskrivelser m.m.) så er oplysningerne derfra ikke ansvarlige om der skal være reserver-knapper på den ene eller anden måde - de vises afhængig af provideren svarer.

Går vi den vej kan de to sager samles i en sag.

#12 Opdateret af Rolf Madsen for næsten 2 år siden

  • Tildelt til ændret fra Tina Skjærbæk Søeborg til Thomas Hansen
  • Udgave ændret fra Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) til Release 27 - Bugfixes (Reload)

#13 Opdateret af Thomas Hansen for næsten 2 år siden

  • Status ændret fra Needs analysis til Needs code review

Fixed: https://github.com/ding2/ding2/pull/588

Løsningen er en smule hackery med at skifte over til at bruge holdings istedet for items hvis der er en reserveringsknap på siden, men det var det der lige var til uden at skulle refaktorere ding_reservations, ding_availability og ding_periodical.

#14 Opdateret af Gitte Barlach for næsten 2 år siden

  • Tildelt til ændret fra Thomas Hansen til Jørgen Nielsen
  • Udgave ændret fra Release 27 - Bugfixes (Reload) til DDB CMS 2017 1. opgradering (Reload sprintbacklog)

#15 Opdateret af Jørgen Nielsen for næsten 2 år siden

  • Status ændret fra Needs code review til Reviewed
  • Tildelt til ændret fra Jørgen Nielsen til Gitte Barlach

reviewet og godkendt

#16 Opdateret af Kasper Garnæs for næsten 2 år siden

  • Status ændret fra Reviewed til Technical test

Merged.

#17 Opdateret af Rolf Madsen for mere end et år siden

  • Status ændret fra Technical test til Closed

#18 Opdateret af Rolf Madsen for mere end et år siden

  • Status ændret fra Closed til Technical test

#19 Opdateret af Simon Holt for mere end et år siden

Jeg har testet dette her ifb. med #1455 og det ser desværre ikke ud til at virke.

Jeg har verificeret at den rent faktisk finder reserveringsknappen her: https://github.com/ding2/ding2/blob/master/modules/ding_availability/js/ding_availability.js#L39, men det får den ikke fjernet alligevel og både "hovedreserveringsknappen" og reserveringsknapperne under "Årgang og numre" vises dermed.

Jeg kan dog godt lide valget af løsning:
1. Vi aktiverer reserveringsknap for alle årbøger under admin/config/ting/reservable
2. Hvis opstillingen viser sig at være en PIF-post og have issues, fjerner/dsiable vi bare "hovedreserveringsknappen"

Vil dog foreslå vi laver noget i den her retning i ding_periodical:

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

Har testet ovenstående og får nu ikke længere en ikke-virkende reserveringsknap på årbøger lavet som en PIF-post

#20 Opdateret af Lotte Tøstesen for mere end et år siden

  • Status ændret fra Technical test til Need more info
  • Tildelt til ændret fra Gitte Barlach til Simon Holt

Hej Simon
Skal lige forstå det rigtigt, har du lavet en rettelse her, som vi skal have codereviewet og merged, eller er det et løsningsforslag som ikke er færdiglavet endnu?? Jeg synes da, det ser ud til at virke - men kan du give mig nogle eksempelmaterialer som fejler?

#21 Opdateret af Simon Holt for mere end et år siden

Hej Lotte

Der er ikke noget der er klar til at bliver merget her.

Jeg kunne ikke få Thomas' fiks til at virke, så prøvede en anden tilgang og fik det til at virke med at den fjernede reservationsknappen, hvis ding_periodical fandt periodiske oplysninger i beholdningsdata.

Det er efterfølgende gået op for mig, at jeg ikke havde taget højde for, at der også skal vises de normale holdings i disse tilfælde.

Men spørgsmålet er, om vi ikke skal droppe det. For har fundet ud af i #1455 at reservation alligevel vil fejle for årbøger, når der ikke kommer en "Årgang og numre", da det er et udtryk for manglende periodica-oplysninger i beholdingen. Der er simpelthen en regel i FBS, der forhindrer reservation, som jeg har forklaret nærmere i #1455. Så hvis "den enkelte" reserveringsknap skal virke, skal vi gentænke koden i disse tilfælde og få periodica-oplysninger til at sende med til FBS API et andet sted.

Har spurgt Systematic om de vil kigge på at ændre den regel der forhindrer reservation, men det skal formuleres som et ændringsønske til Kombit.

Mit forslag er, at vi opfordrer biblioteker til at finde disse problematiske årbøger i Cicero og manuelt at sørge for at periodica-oplysninger er korrekt angivet i behold.

#22 Opdateret af Steen Larsen for mere end et år siden

Måske skulle vi dykke ned i hvorfor pull-requestet ovenfor ikke virker?

Det er vigtigt at vi ikke tester på materialer som helt mangler de periodiske oplysninger for det virker ikke.
Men der er flere materialer som ikke er de kendte periodika-typer men som faktisk alligevel har reelle år/volumen/nummer-informationer.

Som jeg har gjort tidligere i #1545 kan disse materialer søges frem ved at søge på ma=pe og evt. inkludere de underlige typer eller udelade de kendte.

Via facet-søgning på ma=pe kan man finde disse term.typer (her for aakb) som har materialer der er periodika:

  1. årbog, periodikum, tidsskrift
  2. avis, serie
  3. bog, cd (musik), cd-rom, dvd-rom, dvd, graphic novel, mikroform, pc-spil, playstation 2, playstation, sammensat materiale, tegneserie
  4. netdokument, periodikum (net), avis (net), tidsskrift (net)

1) kender vi
2) er nok nogle vi har glemt
3) er de underlige typer
4) skal ikke vise beholdning af andre årsager

De periodika der mangler oplysninger er desværre også inkluderet i ovenstående 1-3

#23 Opdateret af Simon Holt for mere end et år siden

> Men der er flere materialer som ikke er de kendte periodika-typer men som faktisk alligevel har reelle år/volumen/nummer-informationer.

Hvis et materiale har år/volumen/nummer-informationer i bibliotekssystemet kommer "Årgang og numre" automatisk frem uanset materialetype. Der er ikke noget check i DDB CMS på term.type eller lignende her, den kalder bare availability holdings og leder efter issues.

Dette hænger ikke så godt sammen med den valgte fremgangsmåde med at vælge hvilke term.typer der skal have en enkelt reserveringsknap øverst under admin/config/ting/reservable. Så hvis vi skal arbejde videre med det her, synes jeg vi skal kigge på at gentænke dette. Umiddelbart ser jeg to løsninger:

1. Vi beholder modellen med at vinke af under admin/config/ting/reservable, men refaktorerer ding_periodical (der viser "Årgang og numre") og ding_availability (der viser holdings), så den spiller sammen med det. Ergo, der bliver aldrig vist både "Årgang og numre" plus en reserveringsknap øverst og almindelige holdings. Og hvis der eksempelvis kun er en/et år/volumen/nummer præsenterer vi bare en enkelt reserveringsknap. Man vinker bare af under admin/config/ting/reservable og så finder systemet selv ud af at præsentere reservingsmuligheder på den mest hensigstmæssige måde.
2. Vi dropper admin/config/ting/reservable og baserer det hele på beholdingsoplysninger fra bibliotekssystemet, som det er nævnt i http://platform.dandigbib.org/issues/1545#note-7.

2. lyder fristende, men kan der være nogle situationer hvor biblioteker rent faktisk ønsker den kontrol, som 1. giver?

Selv om vi fikser dette, vil det alligevel ikke være muligt at reservere ma=pe materialer uden periodica-oplysninger. Vi kan ikke på nogen måde reservere disse materialer via DDB CMS. Har prøvet at sende tom-streng/null med i alle periodica-felterne, men intet virker i disse tilfælde.

Så problematikken, som den her sag startede med, med at der ikke kommer "Årgang og numre", da der mangler periodica-oplysninger i bibliotekssystemet og disse materailer dermed ikke kan reserveres, kan vi simpelthen ikke løse med rettelser til DDB CMS.

#24 Opdateret af Rolf Madsen for mere end et år siden

  • Status ændret fra Need more info til Needs analysis
  • Udgave ændret fra DDB CMS 2017 1. opgradering (Reload sprintbacklog) til Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1)
  • Kategorier Inspiration - Forsiden tilføjet

#25 Opdateret af Rolf Madsen for mere end et år siden

  • relaterer til Bug #2530: Problemer med reservering af tidsskrifter tilføjet

#26 Opdateret af Rolf Madsen for mere end et år siden

  • Beskrivelse updated (diff)

Er fejlen omkring "at der ikke kommer "Årgang og numre", da der mangler periodica-oplysninger i bibliotekssystemet og disse materailer dermed ikke kan reserveres" meldt ind til Systematic i Sagsnr: 55687, som fremgår af https://platform.dandigbib.org/issues/2530?next_issue_id=2511&prev_issue_id=2532#note-30?

Løser forslag 2 så grundlæggende at Reservér knappen så ikke vises på posten som et "normalt" materiale, hvis et materiale har årgang/nummeroplysninger?

#27 Opdateret af Rolf Madsen for cirka et år siden

  • Udgave ændret fra Release 27 - Bugfixes (2017 2. opgradering) (7.x-4.2.1) til Release 29-2 - Bugfixes (7.x-4.5.0)

#28 Opdateret af Steen Larsen for cirka et år siden

Sagen der blev sendt til systematic i #2530#note-30 skulle være løst, men jeg har mine forbehold jvf #2530#note-49

For at kunne håndtere tom streng/null-værdier i periodical skulle jsonmapper opdateres hvorefter fejl i swagger pludselig blev synlige.
Det vil vise sig om der stadig er fejl.

I #2530#note-42 har jeg nævnt de 3 mulige fejlkilder der er kendt - pkt 1 håndteres af #2530, pkt 2 skal håndteres af personale (tilføj noget i et af de 3 felter) og pkt 3. også af personale (kasser og opret igen) som jeg har forsøgt at beskrive i #3247.

Forslag 2 burde også kunne håndtere afvigende periodikatyper som f.eks. term.type=serie - som på trods af krydser/ikke-krydser i /admin/config/ting/reservable og /admin/config/ting/holdings stadig ikke kan reserveres (jvf den lukkede sag #1545).

Nærværende sag har vel også allerede fået implementeret noget kode jvf note 16 ovenfor og min undren over manglende reserverknap i #3247

 

 

#29 Opdateret af Rolf Madsen for cirka et år siden

Vi har lavet et udviklingsønske til Kombit om at availability response udvides med oplysing om hvorvidt et tidsskrift har årgang- og nummeroplysninger:

/external/{agencyid}/catalog/availability/v3 Get availability of bibliographical records

Response Class AvailabilityV3 {

recordId (string): The FAUST number of the Bibliographic record

reservations (integer): Total number of current active reservations of the Bibliographic record

reservable (boolean): True if materials can be reserved

available (boolean): True if materials is available on-shelf at some placement, false if all materials are lent out

}

Udvides med 

volNumberAvailable (boolean): True if Periodical or Yearbook has a Volume/Number structure

Kan det bidrage til løsningen af ovenstående?

#30 Opdateret af Steen Larsen for cirka et år siden

Nu kan det være lidt svært at gætte hvad funktionaliteten egentlig betyder - jeg vil antage at "or Yearbook" er overflødig og at Year mangler - så der istedet burde stå "has a Volumen/Number/Year structure."

Og så gætter jeg at det er en smart genvej til at checke forekomsten af "periodical"-feltet for alle materialerne (for et givet faust) og så er det IKKE en løsning.

Vi kan løse reserveringerne for de fleste værker/materialer som beskrevet tidligere, men der er undtagelser som ikke kan løses i ddbcms pga fejl i materialernes registreringer (jvf note28). Fejl som FBS-API gladeligt sender videre til ddbcms.

 

#31 Opdateret af Simon Holt for cirka et år siden

Det er noget kompliceret noget det her og der har været lidt forskellige problemer i spil.

Sagen her startede med følgende problem (som også er beskrevet i #1545, der er blevet lukket til fordel for denne sag): Indstillingen for om en materialetype skal have en reseveringsknap, giver ikke mening ift. årbøger.

Som det er nævnt flere gange i denne sag, er det fordi at nogle årbøger er laves som enkeltposter og skal have en reserveringsknap mens andre har den interne struktur med Volumen/Number/Year og skal ikke have en reserveringsknap, men i stedet have en for hver udgivelse under "Årgang og numre". Dette spiller altså ikke sammen med modellen, hvor man en gang for alle tager stilling til, om en materiale-type skal have en reseveringsknap

Der er blevet præsenteret to løsningforslag til dette i denne sag og de er begge lidt hackede løsninger ovenpå den eksisterende model.

https://github.com/ding2/ding2/pull/588 (merged)

https://github.com/ding2/ding2/pull/642 (ikke-merged)

Men vi kom så frem til, at det ikke rigtig gav mening at løse det på den måde alligevel pga den måde FBS håndterer periodica: hvis en post har ma=pe bliver materialerne på posten automatisk inddelt i "eksemplarer" og ved reservation skal man angive nok information i Volumen/Number/Year felterne til at den kan finde det rigtige eksemplar til reservation. 

I de tilfælde hvor der ikke kommer en "Årgang og numre" er det fordi der mangler periodica-oplysninger på eksemplarerne i bibliotekssystemet, så de kan ikke reserveres.

Så jeg er lidt i tvivl om, hvad vi skal lave i denne sag. Biblioteker der ikke får "Årgang og numre" på nogle af deres årbøger, bør rette disse poster i bibliotekssystemet.

Det er ikke sådan lige til at finde alle årbøger, der mangler periodica-oplysninger. Jeg tror vi (Vejle) har fundet og rettet de fleste efterhånden. Vi har bl.a. fået en stor hjælp af Steen, Aarhus, der har en metode til at finde dem.

Så for at opsummere

Det man som bibliotek skal gøre er at deaktivere reserveringsknappen for årbøger under admin/config/ting/reservable og sørge for at periodica-oplysninger er indtastet korrekt, så man får reserveringsknapper under "Årgang og numre".

#32 Opdateret af Steen Larsen for cirka et år siden

Der er to typer reserver-knapper (en "monografi"-knap og "periodika"-knap).

Jeg synes at vi burde arbejde henimod at visningen af knapperne afhang af FBS-API-svaret istedet for dkabm-typerne (som de to pullrequest måske delvist håndterer?).

Udfordringen er dog at der er fejl i FBSAPI-svaret i nogle tilfælde så vi skal have en passende algoritme.
Men måske kan man bruge statistik - er de fleste materialer periodical ifølge FBS er det jo nok et sådant.

#33 Opdateret af Simon Holt for cirka et år siden

Der er to typer reserver-knapper (en "monografi"-knap og "periodika"-knap).

Fint.. lad os bruge den terminologi :) Det er det samme jeg beskriver, bare med andre ord.

Jeg synes at vi burde arbejde henimod at visningen af knapperne afhang af FBS-API-svaret istedet for dkabm-typerne (som de to pullrequest måske delvist håndterer?).

Enig, synes bare det er out of scope i denne sag.

Der er jo også projektet med guldknappen, som muligvis laver om på alt det her.

 

#34 Opdateret af Simon Holt for cirka et år siden

@Steen ved nærmere eftertanke er jeg ikke helt sikker på, jeg har forstået dig rigtig.

Jeg synes at vi burde arbejde henimod at visningen af knapperne afhang af FBS-API-svaret istedet for dkabm-typerne (som de to pullrequest måske delvist håndterer?).

Mener du bare i det her tilfælde med periodika eller mere generelt, så vi helt fjerner det med at man skal indstille hvor der skal være reserveringsknap under /admin/config/ting/reservable?

Det ene PR kigger på om der er mere end en reseveringsknap i frontend og skifter til holdings, hvis det er. Det andet kigger på serveren, om der blev returneret issues i holdings og hvis ja indstiller en javascript setting, der deaktiverer "monografi-knappen" i frontend. Så i den forstand, kan man vel godt sige den kigger på svaret fra FBS API.

Og lige en rettelse:

Har kigget lidt nærmere på den sag med guldknappen: https://platform.dandigbib.org/issues/1460 

Det ser ud til det kun er på avisartikler, tidsskriftsartikler og så vidt jeg kan forstå, kommer det ikke til at ændre på reserveringsknapperne ved periodika.

#35 Opdateret af Steen Larsen for cirka et år siden

Jeg mener der udelukkende skal kigges på svaret fra FBS så der skal netop ikke være mulighed for indstillinger.
På den måde kan du også håndtere de tilfælde hvor dkabm-typen er afvigende (jvf #1545 og #1460#note-22).

Selvfølgelig er der nogle hjørner der så stadig ikke kan håndteres men det kan FBS-API jo heller.

#36 Opdateret af Simon Holt for cirka et år siden

Jeg kan godt se din pointe med at vi har et problem her.

Felter der viser "Årgang og numre" bliver kun vist, hvis invokering af hook_ding_entity_is returnerer at det er en periodical. Som du selv har nævnt, er det lige nu kun hvis dkabm-typen er 'tidsskrift', 'periodikum' eller 'årbog'. Se: https://github.com/ding2/ding2/blob/master/modules/ting/ting.module#L522 

Når jeg laver en ma=pe søgning på vejlebib.dk får jeg 6.045 resultater. Af dem er 4.571 enten 'tidsskrift', 'periodikum' eller 'årbog', hvilket vil sige vi har 6.045 - 4.571 = 1477 materialer, der ikke kan reserveres.

**Rettelse til ovenstående udregning: Jvf. note-22 her. Skal selvfølgelig lige fratrække dem som ikke skal vise beholdning: netdokument, periodikum (net), avis (net), tidsskrift (net). Trækkes disse fra bliver det 1.123 materialer, der ikke kan reseveres.

Måske kunne vi lave det sådan her:

1. ding_reservation modulet tjekker altid om der er holdings. Hvis der er holdings og der ikke returneres periodical informatiom fra holdings kaldet til FBS API, laver den en reseveringsknap.

2. ding_periodical tjekker ligeledes efter holdings, men laver selvfølglelig kun reserveringsknapper hvis der returneres periodical information

Dette vil nok ikke være så svært at lave.

Alternativt, hvis det er for omfattende at ændre i modellen med indstilling af reserveringsknapper for dkabm-typer, kan vi prøve helt at fjerne det tjek på om et materialet er en periodical. Eller måske tilføje de ekstra typer som tilsyneladende også opfattes som periodical i visse situationer.

#37 Opdateret af Simon Holt for cirka et år siden

  • Status ændret fra Needs analysis til Needs design decision
  • Tildelt til ændret fra Simon Holt til Rolf Madsen

#38 Opdateret af Steen Larsen for cirka et år siden

Mht at tilføje ekstra typer til checket så synes jeg ikke det er en god ide men det vil selvfølgelig løse problemet med "avis" og "serie" som (vistnok?) ikke findes i en ikke-periodisk type.

Øvrige typer kan ses/findes ved denne søgning:
ma=pe not term.type any "tidsskrift serie årbog periodikum netdokument"
og det er ganske vist kun få materialer (hos os).

Men det burde kunne laves simpelt:

Spørg FBS hvis kilden er bibliotekskatalog og hvis der er reserver-bare materialer så sæt den rette knap afhængig af feltet periodical.

#39 Opdateret af Simon Holt for cirka et år siden

Men det burde kunne laves simpelt:

Spørg FBS hvis kilden er bibliotekskatalog og hvis der er reserver-bare materialer så sæt den rette knap afhængig af feltet periodical.

Det handler jo også om, ikke at ændre for meget i hvordan tingene er implementeret nu. Lige nu håndteres de to forskellige reseveringsknapper to forskellige steder i to forksellige moduler og det er nok bedst at beholde det sådan.

God pointe med at vi lige skal sikre det er bibliotekskatalog, da vi laver opslag i FBS-API uden namespace. Så:

1. ding_reservation modulet tjekker om der er reserverbare materialer, hvis kilden er bibliotekskatalog. Hvis der er og der ikke returneres periodical informatiom fra holdings kaldet til FBS API, laver den en reseveringsknap.

2. ding_periodical tjekker ligeledes efter reserverbare materialer hvis kilden er bibliotekskatalog, men laver selvfølglelig kun reserveringsknapper, hvis der returneres periodical information.

 

#40 Opdateret af Rolf Madsen for cirka et år siden

  • Status ændret fra Needs design decision til Ready for development
  • Tildelt til ændret fra Rolf Madsen til Simon Holt

#41 Opdateret af Rolf Madsen for cirka et år siden

  • relaterer til Enhancement #3325: Abstraktion af materialetyper for tidsskrifter tilføjet

#42 Opdateret af Rolf Madsen for cirka et år siden

  • Udgave ændret fra Release 29-2 - Bugfixes (7.x-4.5.0) til Release 29-2 - Bugfixes (Vejle)

#43 Opdateret af Kasper Garnæs for cirka et år siden

1. ding_reservation modulet tjekker om der er reserverbare materialer, hvis kilden er bibliotekskatalog. Hvis der er og der ikke returneres periodical informatiom fra holdings kaldet til FBS API, laver den en reseveringsknap.

Reservationsknapper afhænger af hvorvidt materialet bliver identificeret som reservable. Det vil vi i så fald gerne undgå her. Dette kan implementeres igennem noget á la:

function fbs_ding_entity_is($entity, $class) {
  if ($class == 'reservable') {
    // Return FALSE if holdings contain periodical information to make ding_entity_is return FALSE
    // no matter what other implementations might return.
  }
}

Check for kilde er vel allerede muligt på /admin/config/ting/reservable.

 

#44 Opdateret af Rolf Madsen for cirka et år siden

OBS. Vær opmærksom på Kaspers kommentar i https://platform.dandigbib.org/issues/3325#note-4 som behandler "Abstraktion af materialetyper for tidsskrifter".

#45 Opdateret af Rolf Madsen for 9 måneder siden

  • Udgave ændret fra Release 29-2 - Bugfixes (Vejle) til Release 33 - Bugfixes

#47 Opdateret af Simon Holt for 8 måneder siden

Er i gang med at kigge på den her. Ifb. med dette har jeg fundet et yderligere problem. For nogle poster påstår FBS fejlagtigt, at det er et periodikum. Pga. det hack der blev lavet i https://platform.dandigbib.org/issues/1460#note-13, får vi nu slet ingen reserveringsknap på disse poster. Et par eksempler:

https://vejlebib.dk/ting/object/870970-basis%3A42793825 

https://vejlebib.dk/ting/object/870970-basis%3A27719228 

FBS returnerer ellers at de er reserverable: 

https://vejlebib.dk/ding_availability/items/42793825

https://vejlebib.dk/ding_availability/items/27719228

Men når holdings hentes, er de markeret som periodical, så reserveringsknappen fjernes pga https://platform.dandigbib.org/issues/1460#note-13:

https://vejlebib.dk/ding_availability/holdings/42793825

https://vejlebib.dk/ding_availability/holdings/27719228

Jeg har tjekket et par andre biblioteker og de har ikke problemet. I hvert fald ikke på disse poster, men måske på andre?

Min pointe er, at vi tilsyneladende ikke engang kan regne med at FBS har fuldstændig styr på om en post er periodikum.

UPDATE 23-07-2018:

Efter jeg gravede videre i dette, fandt jeg ud af at FBS API returnerer periodical information på et af materialerne og derfor bliver det af DDB CMS markeret som periodical. Hvorfor den returnerer periodical information på disse materialer har jeg ikke regnet ud i endnu. Posten er ikke ma=pe og derfor har vi heller ikke mulighed for at fjerne periodical-informationerne i Cicero. Vi har lavet en sag ved Systematic. Jeg tænker det er noget der er gået galt ifb. med vores data-migrering til FBS. 

Men problemet viser, at det er muligt for FBS API at smide periodical-informationer afsted, selv om en post ikke er ma=pe og man derfor ikke har mulighed for at redigere/indtaste periodical-information i Cicero. Måske kunne vi lave periodical-tjekket mere robust i DDB CMS, sådan at den tjekker alle materialerne for periodical-information. Det bedste ville selvfølgelig være, hvis det blev fikset i FBS sådan at den ikke returnerer periodical for materialer der ikke er ma=pe også selv om der ligger et eller andet databasen.

#48 Opdateret af Simon Holt for 8 måneder siden

Så er der PR: https://github.com/ding2/ding2/pull/1139

Den primære ændring i dette PR er, at vi går fra at det er opensearch, der skal bestemme hvilke materialer der kan reserveres, til at det er library provideren som f.eks. FBS. Det er også den, der burde vide bedst.

Man skal således ikke længere indstille hvilke kilder/typer, der skal have reserveringsknap under /admin/config/ting/reservable. Det finder bibliotekssystemet selv ud af. Det skulle dermed bl.a. fikse det problem vi har med reserveringsknap på årbøger (4.) plus alle de andre problemer nævnt i nedenstående.

Man skal dog stadig (af performance årsager) tage stilling til hvilke kilder, systemet skal spørge om availability-information om. Som standard er det sat til "bibliotekskatalog" i FBS/Opensearch, men man har altså mulighed for at vælge flere typer, hvis der skulle blive brug for det. Lige for at understrege: Denne indstilling medfører ikke, at der kommer reserveringsknap. Den medfører bare at systemet vil spørge bib-systemet om availability og dermed kommer der måske en reserveringsknap for disse materialer.

Problematikkerne med at det ikke er bibliotekssystemet, der afgør om poster kan reserveres, er nævnt flere steder. Jeg prøver lige at opsummere her:

1. Hvilke materialer der skal kunne reserveres, administreres allerede i bibliotekssystemerne. Og for FBS' vedkommende kan man ovenikøbet styre det helt ned på materialeniveau. Så det hænger ganske enkelt ikke sammen med at vi i DDB CMS udelukkende prøver at afgøre udfra materialetyper fra brønden. Det er også lidt dobbelt-konfetti, at det administreres to steder.

2. Når vi får nye materialetyper, skal man altid huske at indstille dette i DDB CMS også. Dette glemmer man at gøre, som vi for eksempel så med Switch-spil, der i en lang periode slet ikke kunne reserveres, fordi bibliotekerne havde glemt at indstille det.

3. For FBS vedkommende: Brøndens typer stemmer ikke overens med det metadata FBS for eksempel anvender til at afgøre om et materiale er periodikum. Det kan giver problemer med poster, der bliver fuldstændig låst udefra at kunne reserveres. Dette er uddybet i https://platform.dandigbib.org/issues/1460#note-36.

4. For nogle materialetyper er det ikke muligt at sige, at den altid er det eller det andet. For eksempel med årbøger, skal nogle af dem have en reserveringsknap fordi de er lavet som enkeltposter, mens andre ikke skal have det, fordi den har periodika-oplysning i beholdning.

Jeg tror grunden til at man har lavet det i første omgang på denne måde har været performance-relateret (for at undgå det ekstra kald til bib-system API). Men med så mange problemer med det, mener jeg det er bedre at løse det på den rigtige måde og lade det system der ved bedst afgøre om et materialer skal kunne reserveres.

#49 Opdateret af Simon Holt for 8 måneder siden

  • Status ændret fra Ready for development til Needs code review
  • Tildelt til ændret fra Simon Holt til Gitte Barlach

#50 Opdateret af Steen Larsen for 7 måneder siden

Lige en kommentar til din update i note47 er netop det tilfælde jeg beskriver i #3247

dvs du ser et materiale som er en almindelig bog og i FBS materialevisning vises den også som en sådan (dvs ingen år/volumen/nummer felter) men felterne ER skam udfyldt - og man kan se det i materiale-søgelisten som i dette eksempel med 3 materialer - læg mærke til () som er den sædvanlige tilføjelse af år/nummer/volumen til titlen

Fejlen er opstået enten ved overgangen fra Ddelibra eller (teoretisk) ved en postændring af DBC

Det er desværre vældigt omstændig at finde dem i FBS og rette dem som beskrevet i #3247. Der er heller ingen hjælp fra Systematic.

 

#51 Opdateret af Gitte Barlach for 5 måneder siden

  • Tildelt til ændret fra Gitte Barlach til Jesper Kristensen

#52 Opdateret af Gitte Barlach for 3 måneder siden

  • Udgave ændret fra Release 33 - Bugfixes til Release 30 - BPI, Kampagneplus og Sektioner (7.x-4.6.0)

Relateret til #3739; sagen fremrykkes derfor.

#53 Opdateret af Simon Holt for 3 måneder siden

Lyder godt :)

Kommer til at se, jeg lige skal have lavet en rebase før den kan merges.

#54 Opdateret af Gitte Barlach for 3 måneder siden

  • Status ændret fra Needs code review til Reviewed - Needs info/rework
  • Tildelt til ændret fra Jesper Kristensen til Simon Holt

ok, tak, Simon:-)
Så ændrer jeg lige status og assigner sagen til dig. 

#55 Opdateret af Simon Holt for 3 måneder siden

Det er super :) jeg får kigget på det!

#56 Opdateret af Christel Krabbenhøft for 2 måneder siden

Hej Simon. Vil du kigge på denne efter din eksamen? :-)

#57 Opdateret af Simon Holt for 2 måneder siden

  • Status ændret fra Reviewed - Needs info/rework til Needs code review
  • Tildelt til ændret fra Simon Holt til Gitte Barlach

PR er rebased og opdateret med et par ekstra rettelser!

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

Det primære i denne rettelse er, at vi spørger FBS hver gang om et materiale er reserverbar. Det holder ikke at basere det på materialetype om et materiale skal have en reserverknap, da der kan være forskel på om materialer er reserverbare indenfor en materialetype. Desuden har det også givet problemer HVER gang der er kommet en ny materialetype og DDB CMS ikke er opdateret til at vise reserveringsknap for den. Hvad der kan reserveres administreres allerede i FBS/Cicero og der er ingen grund til det også skal administreres i DDB CMS.

Jeg er klar over, at der har været lidt problemer med forsinket reserverknap. Men har lige testet PR og selvom den skal lave et kald til FBS for at tjekke reserverbar, kommer alle knapper lynhurtigt. Og det er uden rettelserne fra #3905 og #3739, som får det til at køre endnu bedre.

#58 Opdateret af Gitte Barlach for 2 måneder siden

  • Tildelt til ændret fra Gitte Barlach til Jesper Kristensen

#59 Opdateret af Christel Krabbenhøft for cirka 2 måneder siden

  • Udgave ændret fra Release 30 - BPI, Kampagneplus og Sektioner (7.x-4.6.0) til Release 31 - bugfixes

Pga. tidspres bliver vi nødt til at skubbe sagen til rel. 31. //Christel

#60 Opdateret af Jørgen Nielsen for cirka en måned siden

  • Status ændret fra Needs code review til Reviewed
  • Tildelt til ændret fra Jesper Kristensen til Gitte Barlach

reviewet og godkendt

#61 Opdateret af Simon Holt for en dag siden

Til orientering. Ifb med inkludering af denne rettelse i vores egen kodebase opdagede jeg en mindre fejl som gav en PHP warning. Jeg har opdateret PR med et commit der fikser denne warning:

https://github.com/ding2/ding2/pull/1139/commits/6eb604bc68ae5aa747cc127b1c224d17b957b376 

Det er en meget lille ændring, der ikke har betydning for funktionaliteten.

Eksporter til Atom PDF