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

[Bug 18247] New: Remove SQL queries from branch_transfer_limit.pl administrative script
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18247 Bug ID: 18247 Summary: Remove SQL queries from branch_transfer_limit.pl administrative script Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: alexbuckley(a)catalyst.net.nz Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org This bug report requires all three SQL queries to be removed from branch_transfer_limit.pl administrative script and placed into suitable perl modules in the Koha or C4 directory. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 20596] New: Error Zoom 20003 when import authority marc file (koha/tools/manage-marc-import.pl)
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20596 Bug ID: 20596 Summary: Error Zoom 20003 when import authority marc file (koha/tools/manage-marc-import.pl) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: marjorie.barry-vila(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Created attachment 74361 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=74361&action=ed… authority to test Hi, We have a Zoom error when we apply a matching rule on a field (035) that appears twice in the authority record. ZOOM error 20003 "can't set prefix query" (addinfo: "@or @attr 7=1 @attr 4=109 @attr 1=Local-Number 0 @attr 1=Any @attr 4=1 @attr 5=100 @attr 6=3 "F000001" @attr 1=Any @attr 4=1 @attr 5=100 @attr 6=3 "44444"") from diag-set 'ZOOM' Test plan : - Add a record matching rule for field 035$a (index control-number) - upload a authority record file in tools/stage-marc-import.pl (attached file) - go to Manage staged MARC records and open authority file - apply matching rule for 035 - see error -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 46

[Bug 19693] New: authtypefrom incorrectly set when updating auth recs from file
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19693 Bug ID: 19693 Summary: authtypefrom incorrectly set when updating auth recs from file Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: trivial 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 In those cases when authorities are updated by an external agency (or even internally, by reviewing and correcting an exported authority file) when the heading tag will be changed (seems odd but happens: 111 Congress ==> 110 Corporate body.Congress ; 100 Person ==> 110 Corporate body (a company named with person's name ; 151 City--object ==> 150 Object (city) etc.) and then the authority record in Koha database will be updated with bulkmarcimport or by calling directly ModAuthority from a custom script, the merge function "doesn't know" that the change to the authority type has been made and, consequently, doesn't adequately change the tag in related fields in biblio records (as it would if two different records with different authtypecode were merged with Koha interface). This is because at the moment when merge function is being called by ModAuthority Koha::Authority::Types->find($autfrom->authtypecode) Koha::Authority::Types->find($authto->authtypecode) both have the same value (because $autfrom == $autfrom). Therefore the authtype guessed from the old version of the record should be considered. To test: 1) have an authority record used in biblio; export it to file; change 1XX heading tag to different (but reasonable) value and possibly change also the content of the heading (one can delete also 942 but it doesn't matter); make bulkmarcimport.pl -a -update -file <modified_auth_file> and see that the tag in biblio record has not been changed (whereas the type of authority record did change); 2) make orders in database (so that the authority type and the tag of the field in biblio record correspond); apply the patch; 3) repeat the test from 1). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 27

[Bug 18556] New: Message "Patron's address in doubt" is confusing
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18556 Bug ID: 18556 Summary: Message "Patron's address in doubt" is confusing Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com If a borrower has the patron account flag "Gone no address" set, the message "Patron's address in doubt" appears on the circulation check-out screen. This is confusing -- the borrowers table has the following fields that could be interpreted as an 'address' field: streetnumber streettype address address2 city state zipcode country B_streetnumber B_streettype B_address B_address2 B_city B_state B_zipcode B_country altcontactaddress1 altcontactaddress2 altcontactaddress3 altcontactstate altcontactzipcode altcontactcountry ... and it turns out that the message has *nothing* to do with any of these. I think that the message should read "Patron account flag 'Gone No Address' is set." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 17

[Bug 20457] New: Overdue and pre-overdue cronjobs not skipping phone notices
by bugzilla-daemon＠bugs.koha-community.org 15 Mar '23

15 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20457 Bug ID: 20457 Summary: Overdue and pre-overdue cronjobs not skipping phone notices Change sponsored?: --- Product: Koha Version: master 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The overdue and pre-overdue cron scripts are not skipping the generation of phone notices. This causes many phone notices to be created that will always be left at 'pending' as the Talking Tech outbound script creates its own phone notices and puts them in the message queue. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 26

[Bug 21009] New: Item URIs longer than 255 bytes are silently truncated
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '23

13 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21009 Bug ID: 21009 Summary: Item URIs longer than 255 bytes are silently truncated Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: paul(a)flo.org QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When creating an item in the staff client Koha does not complain if I paste in (or type) a URI that is longer than 255 bytes. When I save the item, the URI is silently truncated to 255 bytes. Here's a sample URI, 500 bytes long, that you can use to reproduce the bug: http://example.com/harumvelitiustovelitofficiaquisnihilconsecteturisteeumau… -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 19454] New: working title
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '23

11 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19454 Bug ID: 19454 Summary: working title Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 39

[Bug 20228] New: Circulation alerts don't take AutoEmailPrimaryAddress system preference into account
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '23

10 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20228 Bug ID: 20228 Summary: Circulation alerts don't take AutoEmailPrimaryAddress system preference into account Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: sophie.meynieux(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In C4::Message->enqueue(), to_address is email or if not defined emailpro or if not defined B_email, irrespective of the value of AutoEmailPrimaryAddress system preference -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21958] New: _check_valid_auth_link checks too many subfields
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '23

04 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21958 Bug ID: 21958 Summary: _check_valid_auth_link checks too many subfields Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org In the sub we call C4::AuthoritiesMarc::GetAuthorizedHeading on the auth record for the field we use all subfields a-z - these are not all valid authorized heading fields To recreate - add a 700 field with $i - link it to an authority with the $i Run the linker in a way that it ends up checking the validity of this link, it will be rejected as not matching This can lead to multiple duplicate authorities being created depending upon settings -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 41

[Bug 16488] New: UNIMARC to MARC21 xslt to be used in z39.50 import sources
by bugzilla-daemon＠bugs.koha-community.org 04 Mar '23

04 Mar '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16488 Bug ID: 16488 Summary: UNIMARC to MARC21 xslt to be used in z39.50 import sources Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Z39.50 / SRU / OpenSearch Servers Assignee: gmcharlt(a)gmail.com Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be very helpful to have at least a 'basic' xsl template to be able to convert UNIMARC data to USMARC when trying to search and import data from UNIMARC z39.50 sources. It seems that there is a generic xslt available for UNIMARC to MARC conversion (https://github.com/edsd/biblio-metadata/blob/master/UNIMARC2MARC21.xsl) but it obviously needs a few changes to work with Koha. -- You are receiving this mail because: You are watching all bug changes.

1 30