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

[Bug 16728] New: Display Issued with entry (MARC21 777) to staff and OPAC normal view
by bugzilla-daemon＠bugs.koha-community.org 09 Nov '20

09 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16728 Bug ID: 16728 Summary: Display Issued with entry (MARC21 777) to staff and OPAC normal view Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: eb(a)efdss.org QA Contact: testopia(a)bugs.koha-community.org The 777 field is not one of the fields currently displayed in staff or OPAC normal view. It is visible in the MARC view, but this does not enable the link (via subfield w) to the related record. The subfields are identical to 773 (which does display in the normal view). The main difference being the automatic text generated by the indicators. http://www.loc.gov/marc/bibliographic/concise/bd777.html This is a very important field for music libraries. -- You are receiving this mail because: You are watching all bug changes.

1 17

[Bug 20023] New: Password recovery should be case insensitive
by bugzilla-daemon＠bugs.koha-community.org 03 Nov '20

03 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20023 Bug ID: 20023 Summary: Password recovery should be case insensitive Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: philippe.blouin(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org When entering an email (or arguably, a userid) to recover the password, a user should not have to know or remember the casing of the given email. Quick exercise for a quick solution led to no results. $search_results = [ Koha::Patrons->search( { -or => { email => $email, emailpro => $email, B_email => $email } } ) ]; Using search_like is not available, and using email => { 'like', $email} does not lead to the intended result. Here's hoping a similarly simple fix exists. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 43

[Bug 19322] New: Typo in UNIMARC field 140 plugin
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19322 Bug ID: 19322 Summary: Typo in UNIMARC field 140 plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dubyk(a)ukr.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Small typo: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=koha-tmpl/intrane… https://books.google.com.ua/books?id=I9rPDkF0_ZQC&pg=PA210&lpg=PA210&dq=uni… Exist: 1499 [% IF ( f14lh ) %] 1500 <option value="lh" selected="selected">erotica</option> 1501 [% ELSE %] 1502 <option value="lh">erotica</option> 1503 [% END %] 1504 [% IF ( f14li ) %] 1505 <option value="li" selected="selected">erotica</option> 1506 [% ELSE %] 1507 <option value="li">erotica</option> 1508 [% END %] Must be: 1499 [% IF ( f14lh ) %] 1500 <option value="lh" selected="selected">erotica</option> 1501 [% ELSE %] 1502 <option value="lh">erotica</option> 1503 [% END %] 1504 [% IF ( f14li ) %] 1505 <option value="li" selected="selected">mystic literature</option> 1506 [% ELSE %] 1507 <option value="li">mystic literature</option> 1508 [% END %] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 15

[Bug 19327] New: Typo in UNIMARC field 128a plugin
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19327 Bug ID: 19327 Summary: Typo in UNIMARC field 128a plugin Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: dubyk(a)ukr.net QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Small typo: http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=koha-tmpl/intrane… Need to replace 259 <option value="p#" selected="selected">partsong</option> with 259 <option value="pt#" selected="selected">partsong</option> -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 15

[Bug 17510] New: marc modification templates ignore subfield $0
by bugzilla-daemon＠bugs.koha-community.org 02 Nov '20

02 Nov '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17510 Bug ID: 17510 Summary: marc modification templates ignore subfield $0 Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org We have realized that Koha MArc modification templates ignore subfield 0, it is not very common used subfield, it is working with subfields greater than 0 We have create a template for adding 773$0 (host biblionumber in analytics) but the template doesn't get the subfield and only stores main tag 773. Checked in: Koha 3.22 & 16.05.05 Debian 8 and plack enabled TEST Go to Tools --> MARC modification templates Create one rule. Add/Update field 773 0 with value 'demo' save it you can check that subfield is not appearing in the descrption, if you edit it appears, but when you try to execute thah template, and try to previwe the marc you get internal error and get the following log. This action is not implemented yet at /usr/share/koha/lib/Koha/SimpleMARC.pm line 169. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 18958] New: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level
by bugzilla-daemon＠bugs.koha-community.org 26 Oct '20

26 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18958 Bug ID: 18958 Summary: If patron has multiple record level holds on one record transferring first hold causes next hold to become item level Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 Imagine you have a record with 3 items, each item is held by LibraryA, LibraryB and LibraryC respectively. Now, a patron places to record level holds for pickup at LibraryD. When any of the items are checked in, that item is trapped to fill the first hold, but a side affect is that the next open hold because item level for the item that was just checked in! This is clearly incorrect and prevents the patron from placing more record level holds on the record. To reproduce: 1. Create and use a patron that can place multiple record level holds per record 2. Create a record with X items, each at a different library 3. Place X 'Next available' holds on the record for the patron using the 'Holds to place' box 4. Check in LibraryA's copy as LibraryA and confirm the hold 5. Revisit request.pl for the record, notice the next hold in line is now item-specific 6. Attempt to place another hold for your patron, notice that it requires an item-specific hold -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 119

[Bug 19718] New: Create message for patrons with multiple holds on the same item
by bugzilla-daemon＠bugs.koha-community.org 21 Oct '20

21 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19718 Bug ID: 19718 Summary: Create message for patrons with multiple holds on the same item Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: karen(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com One of our partners allows 3 holds per record. They have noticed that patrons will place multiple holds on an item that they have already placed on hold. They would like for Koha to display a message to the patron when they place a hold on an item they already have on hold. Their suggested message is "You already have placed a hold on this record. Are you sure you want to place another?" -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 18420] New: t/dbdependent/Budgets.t fails without patron category 'S'
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18420 Bug ID: 18420 Summary: t/dbdependent/Budgets.t fails without patron category 'S' Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: veron(a)veron.ch QA Contact: gmcharlt(a)gmail.com If no patron category 'S' is defined, t/dbdependent/Budgets.t fails. -- You are receiving this mail because: You are watching all bug changes.

1 48

[Bug 17458] New: ID of logged user is displayed when just consult an invoice (parcel.pl)
by bugzilla-daemon＠bugs.koha-community.org 20 Oct '20

20 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17458 Bug ID: 17458 Summary: ID of logged user is displayed when just consult an invoice (parcel.pl) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, When we just consult receipt summary (parcel.pl), the ID of logged user is displayed in field "Received by" But effective receipt were done by someone else. Id of user who done receipt is logged somewhere? Regards, Marjorie -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 17849] New: Show only unpaid fees/fines in OPAC
by bugzilla-daemon＠bugs.koha-community.org 19 Oct '20

19 Oct '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17849 Bug ID: 17849 Summary: Show only unpaid fees/fines in OPAC Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Currently all payments, credits, paid and unpaid fine entries are shown in the OPAC. It would be less confusing, if we only showed unpaid fines and credits. -- You are receiving this mail because: You are watching all bug changes.

1 2