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

[Bug 23540] New: Gender 'N' is not translatable
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23540 Bug ID: 23540 Summary: Gender 'N' is not translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: pasi.kallinen(a)koha-suomi.fi QA Contact: testopia(a)bugs.koha-community.org Patrons of type 'I' (institution) automatically get their sex/gender set to 'N' (which is short for "None"), but the 'N' is not translatable and actually shows up in the patron details page. Relevant code in memberentrygen.tt: [% IF ( I ) %]<input type="hidden" name="sex" value="N" />[% END %] The template code for showing the gender text should be unified into single included file, instead of spread over multiple places like: koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember.tt: [% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %] koha-tmpl/intranet-tmpl/prog/en/modules/members/moremember-brief.tt: [% IF ( patron.sex ) %]<li><span class="label">Gender:</span>[% IF ( patron.sex == 'F' ) %]Female[% ELSIF ( patron.sex == 'M' ) %]Male[% ELSE %][% patron.sex | html %][% END %]</li>[% END %] -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21314] New: Koha enforces 3 character password length even if RequireStrongPassword is disabled
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21314 Bug ID: 21314 Summary: Koha enforces 3 character password length even if RequireStrongPassword is disabled Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons 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, kyle.m.hall(a)gmail.com Bug 18298 added the option to enforce password complexity *if* the new system preference RequireStrongPassword is enabled. However, it appears that the code defining the minimum number of characters was not put under control of this preference and thus Koha enforces a minimum password length of 3 even if RequireStrongPassword is disabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 25

[Bug 20657] New: Globally enable PRE_CHOMP and POST_CHOMP in Template Toolkit configuration
by bugzilla-daemon＠bugs.koha-community.org 18 Mar '24

18 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20657 Bug ID: 20657 Summary: Globally enable PRE_CHOMP and POST_CHOMP in Template Toolkit configuration Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org As it currently stands, the HTML output by Template Toolkit includes whitespace anywhere there was a template tag. For example, this is a portion of the generated source of the staff client home page: 1 2 3 4 <!DOCTYPE html> 5  6 7 8 9 10 <html lang="en"> 11 <head> 12 13 <title>Koha staff client</title> Developer tools report: 26.69 KB / 5.83 KB transferred In contrast, this what the same content looks like with PRE_CHOMP and POST_CHOMP enabled: 1 <!DOCTYPE html> 2  3 <html lang="en"><head> 4 <title>Koha staff client</title> Developer tools report: 23.29 KB / 5.65 KB transferred In the samples I looked at this change did not make the HTML source significantly more difficult to read. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 23

[Bug 19548] New: Search Result Second page not available
by bugzilla-daemon＠bugs.koha-community.org 17 Mar '24

17 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19548 Bug ID: 19548 Summary: Search Result Second page not available Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: koha-bugs(a)lists.koha-community.org Reporter: rainer.stowasser(a)zamg.ac.at QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl With the SRU/Z39.50 search using a quotation mark has the interesting effect that the first page of a result is displayed but a second page is not available. Looking at the pl source it seems that quotation marks are used and escaped for the first page but not for a second recall. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 24192] New: Show host record items in basket/shelves
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '24

15 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24192 Bug ID: 24192 Summary: Show host record items in basket/shelves Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl If EasyAnalyticalRecords is enabled, and if record has no items, display host record items in baskets and lists (staff interface only) Also, show items.enumchron in both pages -- You are receiving this mail because: You are watching all bug changes.

1 14

[Bug 23335] New: "There are no items that can be placed on hold."
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '24

11 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23335 Bug ID: 23335 Summary: "There are no items that can be placed on hold." Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: jmmureithi(a)nationalbank.co.ke QA Contact: testopia(a)bugs.koha-community.org Created attachment 91571 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=91571&action=ed… THE MESSAGE APPEARING IN OPAC The clients/users are trying to place hold and the following message is displayed yet there are items: There are no items that can be placed on hold. -- You are receiving this mail because: You are watching all bug changes.

1 2

[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 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

[Bug 21631] New: No warning when placing a hold with current location/pick-up location combination forbidden by Transport cost matrix
by bugzilla-daemon＠bugs.koha-community.org 05 Mar '24

05 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21631 Bug ID: 21631 Summary: No warning when placing a hold with current location/pick-up location combination forbidden by Transport cost matrix 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: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I might be missing a setting here, holds are so complicated and have so many settings... Plus this is in a multi-branch system situation... I was expecting to see an error or a warning for holds with a combination of current location and pick-up location that is forbidden by transport cost matrix. To reproduce: 0) Make sure you have several branches in your system (at least 3, I'll call them A, B and C) 1) Go to Administration > Global system preferences and activate UseTransportCostMatrix 2) Go to Administration > Transport cost matrix 3) Click on the cell for the combination 'From A to B', uncheck 'Disable' and enter 0 4) Leave combination 'From A to C' disabled 5) In the catalog, search for an item which is currently at library A and currently available (you can use item search for this) 6) Place a hold for this item and change the pick-up location to library B 7) Run misc/cronjobs/holds/build_holds_queue.pl 8) Go to Circulation > Holds queue 9) Choose library A, item should be in the queue 10) In the catalog, search for an item which is currently at library A and currently available (you can use item search for this) 11) Place a hold for this item and change the pick-up location to library C (there is no warning, everything seems fine) 12) Run misc/cronjobs/holds/build_holds_queue.pl 13) Go to Circulation > Holds queue 14) Choose library A, 2nd item is not in the queue Am I missing something? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 24644] New: Hold not marked filled if item set to positive not for loan value
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '24

04 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24644 Bug ID: 24644 Summary: Hold not marked filled if item set to positive not for loan value 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: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Confirmed in master and 19.05. To test: 1: make sure AllowNotForLoanOverride is set to allow 2: place a hold on an item with notforloan=0 3: check item in, confirm hold now shows Waiting 4: edit item, set notforloan to any positive value 5: check item out, performing override to allow checkout 6: confirm hold still shows Waiting Not a situation one expects to see often, but confusing when it pops up. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8