- Koha-bugs - lists.koha-community.org

[Bug 27924] New: Display number of holds awaiting pickup on check out screens
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '21

30 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27924 Bug ID: 27924 Summary: Display number of holds awaiting pickup on check out screens Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com At our pickup window we are pulling patron's holds and checking them out manually. Sometimes it's helpful to know how many items we are looking for on the holds shelves. It would be useful to staff if the number of holds waiting to be picked up displayed on the check out screen above the list of titles. So instead of just seeing 'Holds waiting:" staff could see 'Holds waiting (9) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 18

[Bug 14239] Bibframe support in Koha
by bugzilla-daemon＠bugs.koha-community.org 30 Apr '21

30 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14239 --- Comment #6 from David Cook <dcook(a)prosentient.com.au> --- (In reply to Henry Bolshaw from comment #5) > It sounds like BIBFRAME might be making some slow progress again: > > "The Library of Congress is planning for 2021 to be an expansion year for > its BIBFRAME cataloging operation as a large project involves bringing all > the cataloging staff into BIBFRAME. This means that interchange using both > BIBFRAME and MARC will also expand, as will the potential for new > developments for systems based on either format. This Update will hear about > plans of Ex Libris for Linked Data -- How bridging the BIBFRAME and MARC > workflows might work in the Folio development -- And an OCLC intent to be > able to “adroitly” consume and export BIBFRAME data." > > > https://www.loc.gov/bibframe/news/bibframe-update-mw2021.html Thanks for that, Henry. That's interesting to know! For what it's worth, I don't think we need to worry about a triplestore/graph store for a long time. I think we could already store BIBFRAME records in the biblio_metadata table. I suppose the hardest thing would be deciding whether a particular biblio uses BIBFRAME or MARC as its primary record, and then making sure there was an appropriate transformation at indexing time. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28168] New: Manual invoice form pre-fills Amount field with invalid number
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28168 Bug ID: 28168 Summary: Manual invoice form pre-fills Amount field with invalid number Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Depends on: 27410 The Amount field on Manual invoice form (/cgi-bin/koha/members/maninvoice.pl?borrowernumber=XXXX) used to be empty by default before bug 27410. Now we get a "0.00" or "0,00" value there. This adds one more click to the workflow but more importantly because the form only accepts X.XX (decimal separator being ".") values the pre-filled number is incorrectly in the wrong format if using a comma and it confuses the user because they might think it is okay to enter a comma there. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27410 [Bug 27410] Update intranet-tmpl/prog/en/modules/members/maninvoice.tt to reflect ACC2 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 28157] New: Add the ability to set a library from which an API request pretends to come from
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28157 Bug ID: 28157 Summary: Add the ability to set a library from which an API request pretends to come from Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com Some actions results will depend on the logged-in library, in the Koha UI. For example, extended attributes are not displayed on a library if limits have been set. And the same applies for setting them. Our current code on the API front controller sets userenv with the logged-in patron library. We should add a way to override it through a header, and checks should prevent invalid combinations: i.e. IndependentBranches + patron not superlibrarian => reject the request. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 16787] New: 'Too many holds' message appears inappropriately and is missing data
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16787 Bug ID: 16787 Summary: 'Too many holds' message appears inappropriately and is missing data Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com bug 11250 changed the holds message to be and if,elsif loop, falling through to catch the first appropriate message bug 13116 changed the reporting from CanItemBeReserved causing tooManyHolds to trigger when no holds are allowed A side effect is that 'maxreserves' is only passed to the template when there are too many reserves, but the too many reserves message is called when no holds are available To recreate: Set maxreserves to 50 Set some item type to allow 0 holds Attempt to place a hold on a record with that itemtype Message will be "Too many holds: [Firstname Surname] can only place a maximum of total holds." Message should be "[Firstname Surname] cannot place any holds on these items." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 100

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 --- Comment #49 from Kyle M Hall <kyle(a)bywatersolutions.com> --- Created attachment 120314 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=120314&action=e… Bug 14723: (QA follow-up) Fix typo -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #48 from Kyle M Hall <kyle(a)bywatersolutions.com> --- prove t/db_dependent/Letters.t t/db_dependent/Letters.t .. 6/86 # Failed test 'Time status changed equals time queued when created in message_queue table' # at t/db_dependent/Letters.t line 148. # got: '2021-04-29 13:50:54' # expected: '2021-04-29 00:00:00' t/db_dependent/Letters.t .. 70/86 # Looks like you failed 1 test of 86. t/db_dependent/Letters.t .. Dubious, test returned 1 (wstat 256, 0x100) Failed 1/86 subtests Test Summary Report ------------------- t/db_dependent/Letters.t (Wstat: 256 Tests: 86 Failed: 1) Failed test: 21 Non-zero exit status: 1 Files=1, Tests=86, 4 wallclock secs ( 0.03 usr 0.01 sys + 2.48 cusr 0.39 csys = 2.91 CPU) Result: FAIL -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14723] Additional delivery notes to messages
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14723 Kyle M Hall <kyle(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- QA Contact|testopia(a)bugs.koha-communit |kyle(a)bywatersolutions.com |y.org | -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 28119] New: Use full description in layout type selection
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28119 Bug ID: 28119 Summary: Use full description in layout type selection Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Label/patron card printing Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org I noticed that in C4::Creators::Lib.pm descriptions are defined for layout types. The label layout template uses layout type "names" instead of these descriptions, which I don't think is as helpful. I propose to copy the description text from Lib.pm to use in label-edit-layout.tt as the text for the layout type <option> labels. -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 14300] siplogs do not record process IDs
by bugzilla-daemon＠bugs.koha-community.org 29 Apr '21

29 Apr '21

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14300 --- Comment #7 from Fridolin Somers <fridolin.somers(a)biblibre.com> --- PS : We should consider this also for Plack non ? Since there are several workers. -- You are receiving this mail because: You are watching all bug changes.

1 0