deichman issueshttp://gitlab.deichman.no/digibib/deichman/-/issues2021-03-15T10:26:07Zhttp://gitlab.deichman.no/digibib/deichman/-/issues/141Checkout - Materiale ukendt2021-03-15T10:26:07ZRasmus NielsenCheckout - Materiale ukendt**Checkout**
Ved ukendt materiale, ønskes der (pr. https://rediadev.atlassian.net/browse/DT-219 ) at der returneres "Materialet er ukjent for oss, vennligst kontakt personalet" som fejlbesked.
Vi oplever at vi får denne fejl tilbage fr...**Checkout**
Ved ukendt materiale, ønskes der (pr. https://rediadev.atlassian.net/browse/DT-219 ) at der returneres "Materialet er ukjent for oss, vennligst kontakt personalet" som fejlbesked.
Vi oplever at vi får denne fejl tilbage fra jer: [404].
Hvis vi skal kunne specificere at dette er et ukendt materiale, har vi behov for at få følgende retur “{”error”:“Item not found”}”, ligesom tilfældet er ved checkin.http://gitlab.deichman.no/digibib/deichman/-/issues/140Publications -> items -> barcodes changed to barcode2021-03-11T11:14:50ZRasmus NielsenPublications -> items -> barcodes changed to barcodeWhen I hit the following endpoint, 'GET /api/resources/publication/:id/detailed' with these pubids 'p408cdeee228538edaccdf79d53719e26' and 'p2f23c70615e77a3d965ed11387635676'.
Items contain a field called 'barcode' but following the do...When I hit the following endpoint, 'GET /api/resources/publication/:id/detailed' with these pubids 'p408cdeee228538edaccdf79d53719e26' and 'p2f23c70615e77a3d965ed11387635676'.
Items contain a field called 'barcode' but following the documentation this should be 'barcodes'. Is this a permanent change?http://gitlab.deichman.no/digibib/deichman/-/issues/139wrong error on /api/items/checkout - renewal of material thats reserved2021-02-02T09:28:01ZRasmus Nielsenwrong error on /api/items/checkout - renewal of material thats reservedNår et materiale er reserveret, og der forsøges at forny materialet, bliver der returneret TOO_SOON som fejl, hvor der ønskes ON_HOLD returneret.
Ex
Bruger / Materiale
N002178216 / 03010536146001
Der testet op imod dette endpo...Når et materiale er reserveret, og der forsøges at forny materialet, bliver der returneret TOO_SOON som fejl, hvor der ønskes ON_HOLD returneret.
Ex
Bruger / Materiale
N002178216 / 03010536146001
Der testet op imod dette endpoint: https://redia.test.obib.no/api/items/checkouthttp://gitlab.deichman.no/digibib/deichman/-/issues/138wrong return error on /api/items/checkout2021-02-02T09:24:21ZRasmus Nielsenwrong return error on /api/items/checkoutVed fornyelse af et lån, hvor brugeren har opbrugt sine antal lån, bliver der returneret TOO_SOON som fejl, hvor der ønskes TOO_MANY returneret.
Ex
Bruger / Materiale
N002178207 / 03010457610004
Der er testet op imod dette endpoi...Ved fornyelse af et lån, hvor brugeren har opbrugt sine antal lån, bliver der returneret TOO_SOON som fejl, hvor der ønskes TOO_MANY returneret.
Ex
Bruger / Materiale
N002178207 / 03010457610004
Der er testet op imod dette endpoint
https://redia.test.obib.no/api/items/checkouthttp://gitlab.deichman.no/digibib/deichman/-/issues/137wrong return errors on pi/checkouts2020-11-17T12:50:47ZAsger Juul Møllerwrong return errors on pi/checkoutsVi har opdaget nogle scenarier hvor vi tror i returnere de forkerte fejlbeskeder.
ved Hurtiglån får vi "Du har for mange lån" (too_many). Burde det ikke være noget ligende "cant_renew_fast_loan"?
Fornyelser opbrugte: Du har for mange l...Vi har opdaget nogle scenarier hvor vi tror i returnere de forkerte fejlbeskeder.
ved Hurtiglån får vi "Du har for mange lån" (too_many). Burde det ikke være noget ligende "cant_renew_fast_loan"?
Fornyelser opbrugte: Du har for mange lån. Burde det være noget ligeende "renew_limit_exceeded?
Vil i kigge på dem og tjekke om det er korrekt.http://gitlab.deichman.no/digibib/deichman/-/issues/136På Test miljø får jeg 500 internal service error på /api/patrons/find2020-11-04T12:26:56ZAsger Juul MøllerPå Test miljø får jeg 500 internal service error på /api/patrons/findVi har ved intern test fundet frem til nogle bruger som giver 500 når vi forsøger at fremsøge dem via /api/patrons/find.
De findes i KOHA (test).
Det drejer sig om N002177432 og N002178208.
Vi kan godt finde N002178207.Vi har ved intern test fundet frem til nogle bruger som giver 500 når vi forsøger at fremsøge dem via /api/patrons/find.
De findes i KOHA (test).
Det drejer sig om N002177432 og N002178208.
Vi kan godt finde N002178207.http://gitlab.deichman.no/digibib/deichman/-/issues/135api/items/bylocation mangler materialer fra api/reports/canceledholds og api/...2020-11-26T10:40:32ZMartin Christensenapi/items/bylocation mangler materialer fra api/reports/canceledholds og api/reports/expiredholdsJeg har undersøgt hvad der ligger til grund for https://rediadev.atlassian.net/browse/DT-447
Og en at de ting som kan være skyld i DT-447 er at `api/items/bylocation` ikke ser ud til at indenholde materialer fra `api/reports/canceledhol...Jeg har undersøgt hvad der ligger til grund for https://rediadev.atlassian.net/browse/DT-447
Og en at de ting som kan være skyld i DT-447 er at `api/items/bylocation` ikke ser ud til at indenholde materialer fra `api/reports/canceledholds` og `api/reports/expiredholds`http://gitlab.deichman.no/digibib/deichman/-/issues/134Item Status for ILL materialer2020-09-29T11:40:46ZMartin ChristensenItem Status for ILL materialerNår vi kalder `api/items/status` med en barcode fra en ILL materialer, får vi ikke nogle barcode og ikke nogen metadata, de er begge sat til `null`.
Vi vil meget gerne have noget metadata med ud hvis I har noget, men barcoden skal vi ha...Når vi kalder `api/items/status` med en barcode fra en ILL materialer, får vi ikke nogle barcode og ikke nogen metadata, de er begge sat til `null`.
Vi vil meget gerne have noget metadata med ud hvis I har noget, men barcoden skal vi have fundet en løsning på.
Da barcode på ILL materialet faktisk findes i data'en (bare ikke på den "rigtige" plads), ser jeg et par løsninger:
1. I ændre `api/items/status` så feltet 'barcode' faktisk indenholder barcoden.
2. I beskrive præcis hvordan vi identificere ILL materialer når vi kalder `api/items/status`, og hvordan vi så finde/udregner barcoden for ILL materialer korrekt.
Jeg ser løsning 1. som den korrekte, da logikken omkring at finde den rigtige barcode, burde ligge hos ejeren af data'en, dette vil også forhindre misforståelser omkring hvordan en bruger af `api/items/status` skal finde/udregne den rigtige barcode.Petter Goksøyr ÅsenPetter Goksøyr Åsenhttp://gitlab.deichman.no/digibib/deichman/-/issues/133Missing seenLabel in GET api/items/status/:barcode2020-08-03T14:32:49ZMartin ChristensenMissing seenLabel in GET api/items/status/:barcodeHi
We are missing the field `seenLabel` in the `location` object, when we call `GET api/items/status/:barcode`.
It looks like the field `seenStatus` have been added instead, we are expecting `seenLabel` as the documentation says.Hi
We are missing the field `seenLabel` in the `location` object, when we call `GET api/items/status/:barcode`.
It looks like the field `seenStatus` have been added instead, we are expecting `seenLabel` as the documentation says.http://gitlab.deichman.no/digibib/deichman/-/issues/132Samme sorterings værdi for picks som står samme sted.2020-09-25T08:54:10ZMartin ChristensenSamme sorterings værdi for picks som står samme sted.Hejsa @boutros <br>
Vi havde en samtale på Slack omkring sortering at plukliste materialerne.
---
**Martin - Redia**<br>
Hi petter
Det vi kan gøre er at efter vi har kaldt GET api/picklist/v2, så kan vi tag alle pick's og sortere dem i...Hejsa @boutros <br>
Vi havde en samtale på Slack omkring sortering at plukliste materialerne.
---
**Martin - Redia**<br>
Hi petter
Det vi kan gøre er at efter vi har kaldt GET api/picklist/v2, så kan vi tag alle pick's og sortere dem i et array efter sortingFallback.<br>
Derefter kan vi så overskrive hvert pick's sorting værdi, med værdien af index'et fra sorteringen.<br>
På den måde kan vi altid udtrykke sorteringen med et tal.<br>
Jeg kan ikke præcis sige hvornår vi kan få tid til at lave denne ændring, det skal jeg først lige forhøre mig om.<br>
En anden (og måske bedre) løsning kunne være at I selv lavet sorteringen og sat hvert pick's sorting værdi til værdien af index'et fra en sortering, så ville I også stadig selv have fuld kontrol over sorteringen.
**petter** :palm_tree:<br>
Ja det er et godt forslag, jeg gjør et forsøk!
:+1:
**petter** :palm_tree:<br>
Jeg tror jeg fikk det til, nå er sorting basert på våre kriterier og det ser bra ut i assist, så da trenger dere ikke gjøre noe mer, all justering kan skje på vår side :-)
**Martin - Redia**<br>
Super :-) :+1:
---
Her skulle jeg have været mere præcis, angående hvad vi ville gøre hvis to pick havde samme sortingFallback.<br>
Det er nemmelig vigtig at disse får samme sorteringsværdi.<br><br>
Da I allerede har sortering på plads, kan dette opnås ved først at gruppere alle picks i *et array af array af picks* (`[][]Pick`), og derefter sorter på det først Pick i hver gruppe og så sætte alle picks sorting værdi i gruppen til værdien af index'et fra sorteringen.Petter Goksøyr ÅsenPetter Goksøyr Åsenhttp://gitlab.deichman.no/digibib/deichman/-/issues/131Tilføj sidst updateret felt til GET api/picklist/v22020-06-19T10:04:43ZMartin ChristensenTilføj sidst updateret felt til GET api/picklist/v2Hi
For kunne generere præcise pluklister har vi brug for at vide hvornår den data vi får ud af `GET api/picklist/v2` sidst er fuldt opdateret.<br>
Grunden til dette er at `POST api/picklist/found` og `POST api/picklist/v2/notfound` ikke...Hi
For kunne generere præcise pluklister har vi brug for at vide hvornår den data vi får ud af `GET api/picklist/v2` sidst er fuldt opdateret.<br>
Grunden til dette er at `POST api/picklist/found` og `POST api/picklist/v2/notfound` ikke påvirker `GET api/picklist/v2` med det samme.
En simpel løsning være følgende:
<pre>
{
"updated": Timestamp, // (gerne Unix Time Stamp)
"picks": []Pick // Det gamle response fra `GET api/picklist/v2`
}
</pre>
Her er `updated` det tidspunktet data'en i `picks` sidst er opdateret.http://gitlab.deichman.no/digibib/deichman/-/issues/130Ny pluklist v2 data (Vigtig)2020-06-25T09:16:43ZMartin ChristensenNy pluklist v2 data (Vigtig)Jeg har kigget lidt på pluklist v2 data'en.
1. Det er kun for `bjor` der er en sortering (er allerede nævnt).
2. Der kommer et nyt endpoint: `POST api/picklist/v2/notfound/:barcode`, hvad er return data'en for det endpoint ?
3. Vi kan i...Jeg har kigget lidt på pluklist v2 data'en.
1. Det er kun for `bjor` der er en sortering (er allerede nævnt).
2. Der kommer et nyt endpoint: `POST api/picklist/v2/notfound/:barcode`, hvad er return data'en for det endpoint ?
3. Vi kan ikke (endnu) hente alle picks for alle branches, vi får lige nu et tomt array.
4. Alle `holds->found` har værdien `null`
5. Hvad skal vi bruge `sortingFallback` til ? Vi skal helst ikke til at implementere en fallback sortering.
6. Det ser ud til at `displayLocation->level3` altid er lig med `pickLocation`, det virker forkert.
7. For branch fx. fmaj, så er `displayLocation->level1` lig med branch navn, `level2` er `null` og `level3` er branch code (den samme som `pickLocation`), det virker også lidt sært.
8. Hvordan skal vi bruge `displayLocation` i det nye setup ?
9. Der har tidligere været nævnt i https://gitlab.deichman.no/digibib/deichman/issues/129 at vi måske skulle sende filtre med fx `/api/picklist/v2?branch=bjor&floor=U1&neighbourhood=aapentMagasin&collection=skjoennlitteratur`.<br>Vi vil super gerne vide inden vi starter med at impl. om det er plannen at vi fremtidig skal sende filtre med eller ej ?<br>Hvis vi ikke skal sende filtre med, så er jeg ikke sikker på vi har nogle grund til at sende branch med, så længe det fulde resultat stadig er sorteret.
Kommer der mere ? eller er der noget jeg har overset ?http://gitlab.deichman.no/digibib/deichman/-/issues/129Mulig forvirring hvis vi bruge displayLocation fremover (Vigitg)2020-04-30T18:07:38ZMartin ChristensenMulig forvirring hvis vi bruge displayLocation fremover (Vigitg)Hi
Før I tilføjet `sorting` array'et til picks, brugte vi `displayLocation` til bla. den omtalte gruppering fra https://gitlab.deichman.no/digibib/deichman/issues/127
Nu bruger vi kun `displayLocation` i UI'et (og kun level2 og level3)...Hi
Før I tilføjet `sorting` array'et til picks, brugte vi `displayLocation` til bla. den omtalte gruppering fra https://gitlab.deichman.no/digibib/deichman/issues/127
Nu bruger vi kun `displayLocation` i UI'et (og kun level2 og level3), altså det der vises i App'en er "Level2 > Level3"<br>
Fx. vil følgende vise **2. etg. – Skjønnlitteratur > Asm**
<pre>
"displayLocation": {
"level1": "Bjørvika",
"level3": "Asm",
"level2": "2. etg. – Skjønnlitteratur"
},
</pre>
Skal vi stadig bruger `displayLocation` i UI'et ?
Hvis vi stadig skal bruge `displayLocation` i UI'et kan det give et problem da picks med samme `biblionummer`, `branchId` og `sorting` array kan have forskellige `displayLocation`'s, fx.
<pre>
{
"biblionumber": "25622",
"title": "Men tankene mine får du aldri : roman",
"pick": {
"bjor": [
{
"sorting": [
"",
"Asm",
"Asmervik, Sverre",
"Men tankene mine får du aldri : roman"
],
"pickLocation": "bjor.pub.2.skjoennlitteratur.skjoennlitteratur.a",
"ccode": null,
"itemlost": "0",
"itemnumber": "151",
"displayLocation": {
"level1": "Bjørvika",
"level3": "Asm",
"level2": "2. etg. – Skjønnlitteratur"
},
"location": null,
"itemcallnumber": "Asm",
"category": "Skjønn voksen",
"filtering": [
"pub",
"2",
"skjoennlitteratur",
"skjoennlitteratur",
"a"
],
"barcode": "03010025622001",
"onlyex": null
},
{
"itemnumber": "154",
"ccode": null,
"itemlost": "0",
"sorting": [
"",
"Asm",
"Asmervik, Sverre",
"Men tankene mine får du aldri : roman"
],
"pickLocation": "bjor.pub.2.skjoennlitteratur.skjoennlitteratur.a",
"onlyex": null,
"itemcallnumber": "Asm",
"displayLocation": {
"level1": "Bjørvika",
"level3": "Asm",
"level2": "2. etg. – Skjønnlitteratur"
},
"location": null,
"barcode": "03010025622127",
"category": "Skjønn voksen",
"filtering": [
"pub",
"2",
"skjoennlitteratur",
"skjoennlitteratur",
"a"
]
},
{
"pickLocation": "bjor.pub.U1.aapentMagasin.skjoennlitteratur.a",
"sorting": [
"",
"Asm",
"Asmervik, Sverre",
"Men tankene mine får du aldri : roman"
],
"itemnumber": "156",
"ccode": "mag",
"itemlost": "0",
"barcode": "03010025622132",
"filtering": [
"pub",
"U1",
"aapentMagasin",
"skjoennlitteratur",
"a"
],
"category": "Skjønn voksen",
"itemcallnumber": "Asm",
"displayLocation": {
"level1": "Bjørvika",
"level3": "Asm",
"level2": "Underetasje – Skjønnlitteratur"
},
"location": null,
"onlyex": null
}
],
...
},
...
}
</pre>
Her har alle tre samme `biblionummer`, `branchId` og `sorting` array, men den sidst har en anden `displayLocation`.
Dette vil betyde at den sidste at de tre vil fremstå med lokation **Underetasje – Skjønnlitteratur > Asm**, mens de to første vil have lokation **2. etg. – Skjønnlitteratur > Asm**, selv om de er grupperet på `biblionummer`, `branchId` og `sorting` array https://gitlab.deichman.no/digibib/deichman/issues/127
Når vi gruppere på `biblionummer`, `branchId` og `sorting` array, burde `displayLocation` så ikke være ens ?<br>
**Altså, vores sortering vil sortere de tre eksemplar lige efter hinanden, men deres "display text" vil være forskellige, hvilket vil forvirre brugeren.**
Desuden så kan jeg se at den sidst i `filtering` har etage U1 og de to første har etage 2, men de har samme `sorting` array, hvilket også virker lidt sært.http://gitlab.deichman.no/digibib/deichman/-/issues/128Skal vi stadig bruge pickLocation til at finde den rigtige branch2020-04-14T15:49:05ZMartin ChristensenSkal vi stadig bruge pickLocation til at finde den rigtige branchDa vi lavet pluklister til at starte med, brugte vi key værdien fra `pick` (altså `pick->__BRANCH_ID__`) til at finde hvilken branch et pick stod på.<br>
Det viste sig vi ikke kunne gøre det endnu og at vi skulle bruge `pickLocation` da ...Da vi lavet pluklister til at starte med, brugte vi key værdien fra `pick` (altså `pick->__BRANCH_ID__`) til at finde hvilken branch et pick stod på.<br>
Det viste sig vi ikke kunne gøre det endnu og at vi skulle bruge `pickLocation` da data'en fx. kunne således ud:
<pre>
{
"biblionumber": "25622",
"author": "Asmervik, Sverre",
"pick": {
"hutl": [
{
....
"pickLocation": "bjor.pub.2.skjoennlitteratur.skjoennlitteratur.a"
}
]
},
...
},
</pre>
Kan vi skifte tilbage nu ?http://gitlab.deichman.no/digibib/deichman/-/issues/127Picks på samme lokation (Vigtig)2020-04-15T07:53:02ZMartin ChristensenPicks på samme lokation (Vigtig)Vi har indtil nu bruget `pickLocation` for bjor og `displayLocation` for ikke bjor, for at finde hvilke picks som står samme sted, altså ved sidden af hinanden. Vi bruger dette til at finde ud af hvilken picks vi skal markere som ikke fu...Vi har indtil nu bruget `pickLocation` for bjor og `displayLocation` for ikke bjor, for at finde hvilke picks som står samme sted, altså ved sidden af hinanden. Vi bruger dette til at finde ud af hvilken picks vi skal markere som ikke fundet på pluklister.
Efter Petter har tilføjet `sorting` array'et, regner vi men at vi skal bruge `sorting` array'et til dette, for at undgå at vi skal bruge flere strategier.<br>
Kan vi bruge `sorting` array'et ? eller skal vi også bruge fx. `displayLocation` ?
Dette Issue er oprettet for at sikre at I har godkendt at vi kan lave dette skift.http://gitlab.deichman.no/digibib/deichman/-/issues/126Mere struktur på det nye filtering parameter til pluklister (Vigtig)2020-04-14T07:59:03ZMartin ChristensenMere struktur på det nye filtering parameter til pluklister (Vigtig)Petter har lavet en ny struktur for hvordan vi skal laver filtrerne fremover, dette er lavet for at undgå at vi skal have flere strategier for hvordan vi laver filtre (altså "bjor" vs. ikke "bjor").
Den gamle måde for på hvordan vi lave...Petter har lavet en ny struktur for hvordan vi skal laver filtrerne fremover, dette er lavet for at undgå at vi skal have flere strategier for hvordan vi laver filtre (altså "bjor" vs. ikke "bjor").
Den gamle måde for på hvordan vi lavet filter endtil nu er.
Hvis materialet er på filialen "bjor" bruger vi "pickLocation" indeks (0 indekseret)
<pre>
index 2 => floor
index 3 => section
index 4 => collection
index 5 => subcollection
</pre>
Hvis materialet ikke er på filialen "bjor"
<pre>
Ccode => department
Category => location
</pre>
Så vi har endtil nu arbejdet med 6 forskellige filtre (her har vi ikke tag "findes kun her" med).
Den nye måde vi får filtrerings værdier på er fra en parameter "filtering" som er et array af strenge.
Her er et par eksempler.
<pre>
fsme
"filtering": [
"Barn",
"Bok",
"Fag",
"Eventyr"
],
bjor
"filtering": [
"pub",
"2",
"barn",
"fakta",
"samfunn"
],
</pre>
For at undgå at skulle bruge 2 strategier for filtering fremover skal vi udvide størrelse af "filtering" og definere en mapping fra index til filter.
Denne mapping er den som bestemmer hvad for et filter en værdi i array er og det bestemmer den human readable værdien i UI'et i app'en.
Det er nødvendig med sådan en ændring for at vi kan slippe for 2 strategier, fx. har "Bok" fra fsme samme index som "2" fra bjor og "2" er jo en etage, hvilket jeg går ud fra "Bok" ikke er.
Et eksemple på en mapping kunne se således ud (**kom endelige med et alternativ**):
<pre>
0 => Det nye filter som vi ikke bruger lige nu, den har værdien "pub" ovenfor.
1 => floor
2 => department
3 => section
4 => location
5 => collection
6 => subcollection
</pre>
Denne mapping vil betyde at værdierne at "filtering" overfor kunne se ud på følgende måde.
<pre>
fsme:
"filtering": [
"",
"",
"Barn",
"",
"Bok",
"Fag",
"Eventyr"
],
bjor:
"filtering": [
"pub",
"2",
"",
"barn",
"",
"fakta",
"samfunn"
],
</pre>
Med denne ændring kan vi impl. vi nye filter færdig.http://gitlab.deichman.no/digibib/deichman/-/issues/125hvad betyder pending i GET api/profile/loans?2020-03-12T12:42:18ZAsger Juul Møllerhvad betyder pending i GET api/profile/loans?i GET api/profile/loans får vi `
"estimate": {
"pending": 0,
"error": null,
"estimate": 57
},
` under holds. hvad betyder pending?i GET api/profile/loans får vi `
"estimate": {
"pending": 0,
"error": null,
"estimate": 57
},
` under holds. hvad betyder pending?http://gitlab.deichman.no/digibib/deichman/-/issues/124REDIA_API_KEY med picklist2020-03-03T19:40:05ZMartin ChristensenREDIA_API_KEY med picklistHi
Vi har brug for at man med `REDIA_API_KEY` kan kalde `GET api/picklist`, da vi skal overvåge endpoint'et for ændringer løbende, uden der er en bruger logget ind.
Det vil desuden være en hjælp for os, hvis man også kan bruge `REDIA_A...Hi
Vi har brug for at man med `REDIA_API_KEY` kan kalde `GET api/picklist`, da vi skal overvåge endpoint'et for ændringer løbende, uden der er en bruger logget ind.
Det vil desuden være en hjælp for os, hvis man også kan bruge `REDIA_API_KEY` med `POST api/picklist/found` og `POST api/picklist/notfound/:barcode`.http://gitlab.deichman.no/digibib/deichman/-/issues/123Opret ny låner til Butler2020-02-20T09:40:23ZMagnus PetersenOpret ny låner til ButlerVi skal til at implementere "Opret ny låner" i Butleren, og dertil har vi brug for at få de relevante endpoints udstillet til os.
Jeg tænker vi skal have fat i de samme, som bliver anvendt på jeres nettside.
![image](/uploads/3a4a88bd...Vi skal til at implementere "Opret ny låner" i Butleren, og dertil har vi brug for at få de relevante endpoints udstillet til os.
Jeg tænker vi skal have fat i de samme, som bliver anvendt på jeres nettside.
![image](/uploads/3a4a88bdfb009fc7c0d3de948c3db9ef/image.png)
Udover det første trin med at skrive sine oplysninger ind, er der så mere der skal udfyldes af brugeren, inden oprettelsen er fuldendt?http://gitlab.deichman.no/digibib/deichman/-/issues/122Mulig bug i pickLocation2020-02-18T19:53:29ZMartin ChristensenMulig bug i pickLocationHi
Jeg fandt dette element på pluklisten (fra https://redia.deichman.no)
<pre>
{
"biblionumber": "472330",
"holds": [
{
"priority": "1",
"branch": "frik",
"age": 18,
"reserve_id": "2110740",
"found...Hi
Jeg fandt dette element på pluklisten (fra https://redia.deichman.no)
<pre>
{
"biblionumber": "472330",
"holds": [
{
"priority": "1",
"branch": "frik",
"age": 18,
"reserve_id": "2110740",
"found": null,
"itemnumber": null,
"reservedate": "2020-01-31"
}
],
"pick": {
"hutl": [
{
"barcode": "03010472330001",
"pickLocation": "bjor.pub.4.naturTeknikkHelse.naturfag.matematikk",
"itemnumber": "315079",
"displayLocation": {
"level2": "4. etg. – Naturfag",
"level1": "Bjørvika",
"level3": "519.2 Bjø"
},
...
}
]
},
...
}
</pre>
Jeg under mig over at `pickLocation` er lig med `bjor.*` her, når den nu er under `hutl`.<br>
Er der noget jeg har misforstået, eller er dette en bug ?