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

[Bug 29941] New: Automatic item modification by age should be able to set a value to NULL
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29941 Bug ID: 29941 Summary: Automatic item modification by age should be able to set a value to NULL Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When updating a field via automatic item modification, one can set that field to blank, but cannot set it to NULL. There are instances in which NULL would be more helpful. We should allow that option. Maybe a checkbox on the substitution in the modification rule to tell Koha to delete the current value without setting a new one? As we have in batch item modification? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 26816] New: Remove extra space before comma in staff results item list
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26816 Bug ID: 26816 Summary: Remove extra space before comma in staff results item list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org The result list in staff shows an additional space before the comma in the item listings on the right side. Examples: 4 items , 3 available: 4 items , None available -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 32611] New: Not for loan items don't show the specific not for loan value in OPAC detail page
by bugzilla-daemon＠bugs.koha-community.org 08 Mar '24

08 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32611 Bug ID: 32611 Summary: Not for loan items don't show the specific not for loan value in OPAC detail page Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When viewing a detailed record on the OPAC, we used to see the specific value of Not for loan (e.g. Ordered). Right now, any Not for loan value displays as "Not for loan" no matter what the authorized value description (or description (OPAC)) is. To test: 1. In the staff interface, edit an item 2. Change the Not for loan value to Ordered 3. Save 4. Click on "Normal" to see the detailed record --> Status is "Not for loan (Ordered)" 5. Click on "OPAC view: Open in new window." --> Status is "Not for loan". It should be "Ordered" 6. Try with any not for loan value --> Status stays "Not for loan". It should be whatever value you chose 7. Try changing the descriptions or descriptions (OPAC) in Administration > Authorized values > NOT_LOAN --> Status stays "Not for loan". It should be whatever you put in description (OPAC) or description, if description (OPAC) is empty I tested in 22.05(.07) and it shows Ordered (or whatever value I put). In master, it always shows "Not for loan". -- You are receiving this mail because: You are watching all bug changes.

1 18

[Bug 30220] New: Purchase suggestion defaults to first library
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30220 Bug ID: 30220 Summary: Purchase suggestion defaults to first library Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Patrons will not bother to change to their library. Can we make this default to the logged in patron's home library? -- You are receiving this mail because: You are watching all bug changes.

1 19

[Bug 18729] New: Librarian unable to update hold pickup library from patron pages without "modify_holds_priority" permission
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18729 Bug ID: 18729 Summary: Librarian unable to update hold pickup library from patron pages without "modify_holds_priority" permission 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com A librarian can update a hold's pickup library from the record details page, but not from the patron details or checkout pages unless he or she has the "modify_holds_priority". If the librarian does not, an error is displayed instead. This is do to the fact that on those two pages the API is used and it used the PUT for hold to update all hold fields, which requires this permission. Another endpoint for updating only the pickup location should be added that does not require the "modify_holds_priority" permission. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 70

[Bug 31510] New: The notice template tag helper still uses <<>> sytnax.. we should move to TT instead
by bugzilla-daemon＠bugs.koha-community.org 07 Mar '24

07 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31510 Bug ID: 31510 Summary: The notice template tag helper still uses <<>> sytnax.. we should move to TT instead Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org The notice template param select list when working on a notice template still inserts a <<>> syntax replacement variable.. we should start using [% %] instead to encourage the adoption of TT more widely. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 29824] New: Allow for quick spine labels to be editable for printing
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '24

06 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29824 Bug ID: 29824 Summary: Allow for quick spine labels to be editable for printing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org It would be handy if you could edit quick spine labels after you generate them. In some case you may want to remove to character or add a line break. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 25917] New: Table settings for OPAC are all under biblio-detail
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25917 Bug ID: 25917 Summary: Table settings for OPAC are all under biblio-detail Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When you go to Administration > Table settings > OPAC, currently there are 4 tables that can be configured: course-items-table, course_reserves_table, holdingst, subscriptionst. They are all four under the 'Page: biblio-detail' heading. However that is not true. course-items-table and course_reserves_table and not on the biblio-detail page, but rather on opac-course-details and opac-course-reserves respectively. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34856] New: Move strings in messages.po back into their original file (or move everything into messages.po)
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34856 Bug ID: 34856 Summary: Move strings in messages.po back into their original file (or move everything into messages.po) Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr With all the developments that have been done on translatability, a lot of strings have been moved from staff-prog.po and opac-bootsrap.po to a new file called messages.po. I personally don't understand the purpose of this file. For example, why are some OPAC strings in opac-bootstrap.po and others in messages.po? Why are they not all in messages.po or all in opac-bootstrap.po? We could move opac strings back from messages.po back into opac-bootstrap.po and staff interface strings back into staff-prog.po. Or we could move everything into a single .po file. There are good arguments on both sides, and I am open to discussing the various options. I just want it to be less confusing for people who are translators and don't necessarily know the technical stuff behind the creation of these files. P.S. Note that I'm not talking about messages-js.po which is an entirely different thing. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21302] New: Link in 780/785 should search for $t in title and $a in author
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21302 Bug ID: 21302 Summary: Link in 780/785 should search for $t in title and $a in author Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org When a record has a 780 and/or 785 field with both $a and $t, the link should search for the value in $a in the author index and the value in $t in the title index, combined with AND. Right now, it searches for both in the title index. Steps to reproduce: 1- If its not already in your cataloguing framework, add 780 $a and $t and 785 $a and $t (check the "Editor" box) 2- Search for a record and edit it 3- Add an author name in 780 $a and 785 $a 4- Add a title in 780 $t and 785 $t 5- Make sure both indicators for both fields are 0, so it should look like 780 00 $aAuthor1 $tTitle1 785 00 $aAuthor2 $tTitle2 6- Save the record and view it in "normal" view 7- Click the link created for Author1 Title 1 -> the search is ti,phr:Author1 Title1, but it should be au,phr:Author1 and ti,phr:Title1 8- Repeat step 7 with Author2 Title2, same result If possible, it would be great if all values were searched in their rightful index with "and" in between to narrow the search. 76X - 78X $a = author (same as 1XX or 7XX) $d = publisher, publication date or place (same as 260 $a, $b, $c or 264 $a, $b, $c) $e = language (same as 008/35-37) $f = publication place (same as 008/15-17) $k = series (same as 4XX or 8XX) $o = identifier number (same as 0XX) $p = title (same as 210) $s = uniform title (same as 240 or 243) $t = title (same as 245 or 130) $u = report number (same as 027) $x = issn (same as 022) $y = coden (same as 030) $z = isbn (same as 020) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9