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/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/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/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/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 ?http://gitlab.deichman.no/digibib/deichman/-/issues/111Koha skal kunne opdatere pluklister (Vigtig)2020-02-14T09:41:58ZMartin ChristensenKoha skal kunne opdatere pluklister (Vigtig)Der er vist en forventning (eller der har været noget snak om) at vores pluklister automatisk skal opdateres når et materiale manuel markeres som "found" i Koha.
For at vi kan "automatisk" opdatere vores pluklister, skal vi have fundet ...Der er vist en forventning (eller der har været noget snak om) at vores pluklister automatisk skal opdateres når et materiale manuel markeres som "found" i Koha.
For at vi kan "automatisk" opdatere vores pluklister, skal vi have fundet en måde at (næsten live) udveksle, om et materiale manuelt er blevet markeret som "found" i Koha.
En simple løsning kunne være at, vi udstiller et endpoint, hvor Koha så sende den nødvendig information, hver gang et materiale manuelt er blevet markeret som "found" i Koha.http://gitlab.deichman.no/digibib/deichman/-/issues/106Butler - eposter (Lån, reservationer og mellemværende) (Roadmap 2020)2019-12-19T09:19:02ZMartin ChristensenButler - eposter (Lån, reservationer og mellemværende) (Roadmap 2020)Jeg har fået at vide at Butler'en skal kunne sende mail's med brugerens (Lån, reservationer og mellemværende).
Så vi skal bruge tre endpoint's til:
* Send mail med en brugers lån
* Send mail med en brugers reservationer
* Send mail med e...Jeg har fået at vide at Butler'en skal kunne sende mail's med brugerens (Lån, reservationer og mellemværende).
Så vi skal bruge tre endpoint's til:
* Send mail med en brugers lån
* Send mail med en brugers reservationer
* Send mail med en brugers mellemværendehttp://gitlab.deichman.no/digibib/deichman/-/issues/101Forklaring af "loc" feltet. (Vigtig) (Roadmap 2020)2019-12-19T09:18:51ZMartin ChristensenForklaring af "loc" feltet. (Vigtig) (Roadmap 2020)Når vi viser et materiales historik (via. kaldet `GET api/items/history/:barcode`), skal vi vise hvilken filial en handling er udført på og hvem/hvad der har fortaget denne handling.
Vi forventer vi skal bruge `loc` til dette. Vi har fø...Når vi viser et materiales historik (via. kaldet `GET api/items/history/:barcode`), skal vi vise hvilken filial en handling er udført på og hvem/hvad der har fortaget denne handling.
Vi forventer vi skal bruge `loc` til dette. Vi har før skrevet samme omkring hvordan vi skal fortolke `loc`. Filial er nemt nok at finde ud af, men om det var en ansat, en automat eller noget helt tredje som udførte handlingen ved vi ikke.
Her er nogle eksempler:
<pre>
"loc": "fgam.auto.in"
</pre>
<pre>
"loc": "fgam.staff.in"
</pre>
<pre>
"loc": "hutl.skjoennlitteratur.a"
</pre>
Hvordan skal vi fortolke `loc` for at få denne information ud ?http://gitlab.deichman.no/digibib/deichman/-/issues/94Søgningen er begyndt at returner et forkert antal resultater (Roadmap 2020)2020-08-18T12:23:41ZMartin ChristensenSøgningen er begyndt at returner et forkert antal resultater (Roadmap 2020)Vi oplever at søgningen returnere et andet antal hits end forventet.
Fx. https://redia-api-test.ssl.deichman.no/api/search?q=harry%20potter&pageSize=22&page=1<br>
Hvis vi søger på `harry potter` med `pageSize=22` får vi 22 resultater so...Vi oplever at søgningen returnere et andet antal hits end forventet.
Fx. https://redia-api-test.ssl.deichman.no/api/search?q=harry%20potter&pageSize=22&page=1<br>
Hvis vi søger på `harry potter` med `pageSize=22` får vi 22 resultater som forventet. Hvis vi nu ændre `page` til 2, da får vi 31 resultater tilbage. Nu vil vi forventer at der ikke er flere resultater da der var mindre end 44 resultater (og `totalHits` ikke er pålidelig), men hvis vi ændre `page` til 3 får vi 46 resultater.
Når `page`>1, forventer vi at skal fjerne (`page`-1)*`pageSize` fra søge resultatet for at får det resultat vi skal bruge.http://gitlab.deichman.no/digibib/deichman/-/issues/74SSO mere enkelt flow (roadmap 2020)2019-12-19T09:18:17ZMartin ChristensenSSO mere enkelt flow (roadmap 2020)Når vi skal logge ind med SSO via https://sso-test.ssl.deichman.no/oauth/authorize?client_id=redia&response_type=token&redirect_uri=https://platform-staging.libry.dk/api/assist/deichmanbib/auth/token
Så rammer man følgende skærm:<br>![S...Når vi skal logge ind med SSO via https://sso-test.ssl.deichman.no/oauth/authorize?client_id=redia&response_type=token&redirect_uri=https://platform-staging.libry.dk/api/assist/deichmanbib/auth/token
Så rammer man følgende skærm:<br>![SSO_first_step](/uploads/99a2c2e4ced997822684e0d018330798/SSO_first_step.png)
Vi vil gerne ha' at I springer over dette punkt, ved bare at redirect til https://sso-test.ssl.deichman.no/login/oslo så brugeren får et lidt nemmere flow.
Er det mulig at få lavet ?