July 2023 - Koha-bugs - lists.koha-community.org

[Bug 18768] New: Add the ability to authenticate patrons against other ILSs via SIP2
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18768 Bug ID: 18768 Summary: Add the ability to authenticate patrons against other ILSs via SIP2 Change sponsored?: Sponsored Product: Koha Version: master Hardware: All URL: https://github.com/kylemhall/Koha/commits/sip2_client 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 This feature allows Koha use to use other ILSs as an authenticate target in a manner someone similar to how we authenticate LDAP. It allows Koha to be configured with a list of external SIP2 servers to authenticate against. Koha will find the correct server to use based on the order and cardnumber prefix chosen, send a patron information request and handle the patron login based on the response. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 10

[Bug 26641] New: link_bibs_to_authorities.pl: Add the ability to specify the MARC field to operate on
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26641 Bug ID: 26641 Summary: link_bibs_to_authorities.pl: Add the ability to specify the MARC field to operate on 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: a.roussos(a)dataly.gr QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz When running link_bibs_to_authorities.pl, it could be useful to have the ability to specify which MARC field the script should operate on. For example, when you have a catalog where most links are in place, and you don't want the script to process every MARC field but rather limit it to a specific MARC field (e.g. 700) because you've observed that there are many missing links for that particular MARC field. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 26

[Bug 33045] New: Use process_tt in C4::Record::marcrecord2csv
by bugzilla-daemon＠bugs.koha-community.org 18 Sep '23

18 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33045 Bug ID: 33045 Summary: Use process_tt in C4::Record::marcrecord2csv 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 Bug 33030 implements a new helper subroutine to standardize processing of Template Toolkit syntax outside slips and notices. We should use this subroutine in marcrecord2csv. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 13

[Bug 26117] New: itemlost_on value should be updated when item changes from one lost value to another
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26117 Bug ID: 26117 Summary: itemlost_on value should be updated when item changes from one lost value to another Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl To recreate: - set an item to lost=1 - get the itemlost_on value for your item from the database - change the item to lost=2 - get the itemlost_on value again, confirm that the time hasn't changed I'm sort of torn on this. Just now, we ran into an issue where it we needed to know when a lost value was changed. But I can also imagine a situation where one would want to know when an item became lost originally. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 26112] New: Errors in marc21_authorities files for uk-UA
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26112 Bug ID: 26112 Summary: Errors in marc21_authorities files for uk-UA Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: b.pastern4k(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Created attachment 107630 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=107630&action=e… uk-UA fixed queries for default authority Upon fresh install when I choose to add authorities, the following error shows near every authorities file install.pl: DBD::mysql::st execute failed: Incorrect integer value: '' for column `koha_sql`.`auth_tag_structure`.`repeatable` at row 1 After completing install, I tried executing those SQL commands in phpmyadmin and it seems that in mandatory and repeatable columns have values '' or 1. I tried replacing those empty strings with zero and it worked. Seems like each SQL query in those files should be checked and columns mandatory, repeatable should only have values 0 or 1 as it is type tinyint(4). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 17350] New: Add option to delete data stored in saved_reports
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17350 Bug ID: 17350 Summary: Add option to delete data stored in saved_reports Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org This is a follow-up bug to bug 14435 which reactivates an old feature that allows you to store the results of a run report in saved_reports. Now that this will work again, there should also be an option to clean up the data stored - either from the script, the GUI or ideally from both. -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 26107] New: Add ability to delete saved SQL report results
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26107 Bug ID: 26107 Summary: Add ability to delete saved SQL report results Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Currently we can generate report output to be presented in the Koha interface in a scheduled fashion, but we cannot delete any of the previous runs, either automatically via a scheduler or on the fly from the interface. I propose we add two functions: 1. the ability to delete individual saved report results from the Koha interface (a link or a button near the run a user might like to delete) 2. the ability to have a flag for cleanup_database to remove saved report results older than a syspref'd number of days. Please, don't make it a number on the cron definition - we want libraries to be able to control it themselves from the interface. This can potentially reduce the reliance on e-mail as a delivery mechanism for saved reports, which in certain circumstances can be less reliable than we'd hope. Liz -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 32311] New: Add option to delete saved reports results from staff interface
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32311 Bug ID: 32311 Summary: Add option to delete saved reports results from staff interface Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrewfh(a)dubcolib.org QA Contact: testopia(a)bugs.koha-community.org Once a set of report results has been saved, there's no way to delete those saved values. Bug 17350 adds a way to delete them via cleanup_database, but it would also be good to have a way to delete them from the staff interface. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 26028] New: Allow HoldsToPullStartDate to be blank
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26028 Bug ID: 26028 Summary: Allow HoldsToPullStartDate to be blank Change sponsored?: --- Product: Koha Version: 19.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When a patron places a hold, then suspends it, and later unsuspends it, the hold will not show on the Holds to Pull list unless the date is set to include the original hold date. This date range is controlled by the system preference HoldsToPullStartDate. When you leave that system preference blank, the system still defaults to 2 days. Libraries should have the option of leaving the system preference blank to show ALL holds that need to be pulled regardless of the original hold date. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 26025] New: Data loss issue during Schema database upgrade from 16.11 to 20.05
by bugzilla-daemon＠bugs.koha-community.org 16 Sep '23

16 Sep '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26025 Bug ID: 26025 Summary: Data loss issue during Schema database upgrade from 16.11 to 20.05 Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: mishravk79(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Hi While trying to run database upgrade command from Koha 16.11 to 20.05 it gives following error: Upgrade to 16.12.00.003 done (Bug 17486 - Remove 'Mozilla Persona' as an authentication method) DBD::mysql::db do failed: Cannot add or update a child row: a foreign key constraint fails (`koha_library`.`deletedbiblio_metadata`, CONSTRAINT `deletedbiblio_metadata_fk_1` FOREIGN KEY (`biblionumber`) REFERENCES `deletedbiblio` (`biblionumber`) ON DELETE CASCADE ON UPDATE CASCADE) [for Statement " INSERT INTO deletedbiblio_metadata ( biblionumber, format, marcflavour, metadata ) SELECT biblionumber, 'marcxml', 'CHANGEME', marcxml FROM deletedbiblioitems; "] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 13816. Above seems to be data loss under deletedbiblioitem etc. as per discussion over Koha mailing list? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4