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

[Bug 30122] New: Display note fields in authority result list
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30122 Bug ID: 30122 Summary: Display note fields in authority result list Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 35328] New: Add a notes pop-up for authority records to authority search results
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35328 Bug ID: 35328 Summary: Add a notes pop-up for authority records to authority search results Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 38344] New: Dont send "Thank you !" as screen message
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38344 Bug ID: 38344 Summary: Dont send "Thank you !" as screen message Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org $ grep -rn "Thank you !" * C4/SIP/ILS.pm:317: return (1, 'Thank you !', ''); We should remove the space before the exclamation. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 17

[Bug 38742] New: C4::AuthoritiesMarc::merge should call ModBiblio only if really needed
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38742 Bug ID: 38742 Summary: C4::AuthoritiesMarc::merge should call ModBiblio only if really needed Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: januszop(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently, the function C4::AuthoritiesMarc::merge calls ModBiblio for all bibliographic records linked to the modified authority record. It could seem a just behavior but we know that this could lead to performance problems. This is why AuthorityMergeLimit systempreference with merge_authorities.pl was introduced (earlier: dontmerge). Although this partially solves the performance problems, for moderately large and large catalogs (500+ K) and authority records linked with a large number of bibliographic records, performance problems still occur, even with overnight processing with merge_authorities.pl. This problem is particularly apparent when updating authority records from central databases, whose modifications are beyond our control. It turns out, however, that many such modifications to authority records involve fields other than the heading field (1XX in MARC 21), so these updates in fact do not modify bibliographic records. However, with the current merge function, every touch on an authority record forces a call to the ModBiblio function. The number of relatively expensive ModBiblio calls could be reduced by checking whether there has been an actual change in the field associated with the authority record. However, with IncludeSeeFromInSearches or IncludeSeeAlsoFromInSearches preferences enabled, the record should be refreshed in the search engine just in case (should the 4XX, 5XX fields have changed, which we don't know at this point). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 38743] New: Links to UNIMARC field manuals are broken
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38743 Bug ID: 38743 Summary: Links to UNIMARC field manuals are broken Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: baptiste.wojtkowski(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: aude.charillon(a)ptfs-europe.com, philip.orr(a)lmscloud.de In UNIMARC, links to IFLA are broken and referring to a very old version of MARC format. 502 function _UNIMARCFieldDoc(field) { 503 /* http://archive.ifla.org/VI/3/p1996-1/ is an outdated version of UNIMARC, but 504 seems to be the only version available that can be linked to per tag. More recent 505 versions of the UNIMARC standard are available on the IFLA website only as 506 PDFs! 507 */ 508 var url; 509 if (field == 0) { 510 url = "http://archive.ifla.org/VI/3/p1996-1/uni.htm"; 511 } else { 512 var first = field.substring(0,1); 513 url = "http://archive.ifla.org/VI/3/p1996-1/uni" + first + ".htm#"; 514 if (first == 0) url = url + "b"; 515 url = first == 9 516 ? "http://archive.ifla.org/VI/3/p1996-1/uni9.htm" 517 : url + field; 518 } 519 window.open(url); 520 } To my knowledge, there is no good solution to this pb : - According to the code and to my investigation, IFLA is not providing split files, field by field (except fields which have been updated after 2008, which can be accessed through the atomic updates) - transition-bibliographique.fr is providing such a work but only in french -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 15461] Add staff equivalent for OpacLocationOnDetail
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #39 from Jonathan Druart <jonathan.druart(a)gmail.com> --- Hum maybe I am mixing up OpacLocationOnDetail and OpacLocationBranchToDisplay again... -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add staff equivalent for OpacLocationOnDetail
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #38 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #36) > Re bug 27572 it seems that we want to get rid of the pref. Maybe we can ditch the system preference all together and just add shelving location as its own column, configued by Table settings? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 15461] Add staff equivalent for OpacLocationOnDetail
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15461 --- Comment #37 from Lucas Gass (lukeg) <lucas(a)bywatersolutions.com> --- (In reply to Jonathan Druart from comment #36) > Re bug 27572 it seems that we want to get rid of the pref. Are you saying this can't move forward? -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 22403] New: Temporary Card
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22403 Bug ID: 22403 Summary: Temporary Card Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Target Milestone: --- We are CONSTANTLY having to write out patron card numbers on post-its for patrons that forgot their library cards. It would be great if there were an option under the print options on the patron page to print a temporary card. It could print the barcode and number, and maybe have an optional customizable message. Even better, since patrons are prone to leave these lying around, maybe it prints a temporary number that ISN'T their card number, but it is a temporary secondary number linked to their account that expires in X amount of hours. We could hand that out to them, providing of course they provide a photo id to prove who they are. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 38186] New: Cancelling a hold from the holds over tab shouldn't trigger "return to home" transfer on a lost item
by bugzilla-daemon＠bugs.koha-community.org 18 Dec '24

18 Dec '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38186 Bug ID: 38186 Summary: Cancelling a hold from the holds over tab shouldn't trigger "return to home" transfer on a lost item Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Sometimes, when cancelling waiting holds that have expired, the book on hold cannot be found on the holds shelf. In this case, the librarian would mark the item missing/lost and cancel the hold. However, if the librarian sets the lost status first and then cancels the hold on an item that would normally trigger a "return to home" transfer, the transfer still gets triggered and the lost status is removed, which is confusing and inaccurate. If the item is already marked as lost, it should stay lost and shouldn't generate a transfer. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15