April 2021 - Koha-bugs - lists.koha-community.org

[Bug 22276] New: Add client storage of user-selected DataTables configuration
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '24

06 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22276 Bug ID: 22276 Summary: Add client storage of user-selected DataTables configuration Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- DataTables has a "stateSave" option which uses's the browser's local storage to "remember" how someone last changed the configuration of a DataTable: columns settings, filters, etc. This option doesn't work by default because we always load the configuration stored in Columns Settings. I propose to add a function which will check for the existence of a locally-store table configuration before defaults are loaded. -- You are receiving this mail because: You are watching all bug changes.

1 34

[Bug 24334] New: Barcode should be included in Marcitemfieldstoorder
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '24

06 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24334 Bug ID: 24334 Summary: Barcode should be included in Marcitemfieldstoorder Change sponsored?: --- Product: Koha Version: 19.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: kelly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When libraries are ordering shelf-ready books, most of these records from the vendor include a barcode. The system preference marcitemfieldstoorder, does not accept a barcode to be included in this system preference, so the library can not save the barcode of the item that they are receiving. Currently, there are a lot of item level fields that can be used such as a non-public note, public note, URI, call number, etc. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 25424] New: Document our exceptions
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '24

06 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25424 Bug ID: 25424 Summary: Document our exceptions Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Developer documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We should list our different exceptions and explain when to use them. Maybe a wiki page? Also the naming should be more consistent. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 24326] New: Problem with advance_notices_digest.t
by bugzilla-daemon＠bugs.koha-community.org 06 Jan '24

06 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24326 Bug ID: 24326 Summary: Problem with advance_notices_digest.t Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 20478 (In reply to Jonathan Druart from comment #26) > There is something terribly wrong with this test file, the cronjob script is > run outside the transaction and so changes are effective. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20478 [Bug 20478] Advance notices: send separate digest messages per library -- You are receiving this mail because: You are watching all bug changes.

1 12

[Bug 18908] New: Warning "Compatibility levels before 9 are deprecated"
by bugzilla-daemon＠bugs.koha-community.org 05 Jan '24

05 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18908 Bug ID: 18908 Summary: Warning "Compatibility levels before 9 are deprecated" Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: mtompset(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org CC: mirko(a)abunchofthings.net The following output: dh: Compatibility levels before 9 are deprecated (level 7 in use) dh_testdir -O--fail-missing dh_auto_clean -O--fail-missing dh_auto_clean: Compatibility levels before 9 are deprecated (level 7 in use) dh_clean -O--fail-missing is given when trying to following these instructions: https://wiki.koha-community.org/wiki/Building_Debian_Packages_-_The_Easy_Way -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 11

[Bug 25446] New: Terminology: Replace relatives by other term? (family members, group members...)
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '24

04 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25446 Bug ID: 25446 Summary: Terminology: Replace relatives by other term? (family members, group members...) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement 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 I've been wondering if relatives is a good term to use in Koha context. In times where families are not all related to each other, maybe using another term would be nicer and more inclusive? -- You are receiving this mail because: You are watching all bug changes.

1 4

[Bug 28267] New: Koha-common package upgrade problem from 20.05.xx to 20.11.04-1
by bugzilla-daemon＠bugs.koha-community.org 04 Jan '24

04 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28267 Bug ID: 28267 Summary: Koha-common package upgrade problem from 20.05.xx to 20.11.04-1 Change sponsored?: --- Product: Koha Version: 20.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (command-line installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: skaman.tx(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Our koha installation is on Debian 10. Upgrade challenges str specifically related to the outcome of the Debian package koha-common upgrade scripts. We are stuck at koha-common version 20.05.xx at this point. My latest attempt to upgrade to 20.11.04-1 resulted in the following three error messages. Is there any way to manually alter the correct table(s) to fix the database issues? I'm not sure what the "Failed to enable unit" message means. ---------------------------- Setting up koha-common (20.11.04-1) ... Installing new version of config file /etc/cron.daily/koha-common ... Installing new version of config file /etc/init.d/koha-common ... Installing new version of config file /etc/koha/SIPconfig.xml ... Installing new version of config file /etc/koha/apache-shared-intranet-plack.conf ... Installing new version of config file /etc/koha/apache-shared-intranet.conf ... Installing new version of config file /etc/koha/apache-shared-opac.conf ... Installing new version of config file /etc/koha/koha-conf-site.xml.in ... Installing new version of config file /etc/koha/log4perl-site.conf.in ... Installing new version of config file /etc/koha/plack.psgi ... Installing new version of config file /etc/koha/zebradb/etc/phrases-icu.xml ... Installing new version of config file /etc/koha/zebradb/etc/word-phrase-utf.chr ... Upgrading database schema for [database] ....... Upgrade to 20.06.00.031 done [10:19:38]: Bug 22789 - Add non_priority column on reserves and old_reserves tables DBD::mysql::db do failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [for Statement "ALTER TABLE `items` ADD COLUMN `exclude_from_local_holds_priority` tinyint(1) default NULL AFTER `new_status`"] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 22709. DBD::mysql::db do failed: Row size too large. The maximum row size for the used table type, not counting BLOBs, is 8126. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs [for Statement "ALTER TABLE `deleteditems` ADD COLUMN `exclude_from_local_holds_priority` tinyint(1) default NULL AFTER new_status`"] at /usr/share/koha/intranet/cgi-bin/installer/data/mysql/updatedatabase.pl line 22715. ...... Failed to enable unit: Unit /run/systemd/generator.late/koha-common.service is transient or generated. ---------------------------- NOTE: When I then run "/usr/share/koha/bin/migration_tools/rebuild_zebra.pl -b -a -z" in this post-upgrade state I get the following error for each biblio record: DBD::mysql::st execute failed: Unknown column 'me.exclude_from_local_holds_priority' in 'field list' [for Statement "SELECT `me`.`itemnumber`, `me`.`biblionumber`, `me`.`biblioitemnumber`, `me`.`barcode`, `me`.`dateaccessioned`, `me`.`booksellerid`, `me`.`homebranch`, `me`.`price`, `me`.`replacementprice`, `me`.`replacementpricedate`, `me`.`datelastborrowed`, `me`.`datelastseen`, `me`.`stack`, `me`.`notforloan`, `me`.`damaged`, `me`.`damaged_on`, `me`.`itemlost`, `me`.`itemlost_on`, `me`.`withdrawn`, `me`.`withdrawn_on`, `me`.`itemcallnumber`, `me`.`coded_location_qualifier`, `me`.`issues`, `me`.`renewals`, `me`.`reserves`, `me`.`restricted`, `me`.`itemnotes`, `me`.`itemnotes_nonpublic`, `me`.`holdingbranch`, `me`.`timestamp`, `me`.`location`, `me`.`permanent_location`, `me`.`onloan`, `me`.`cn_source`, `me`.`cn_sort`, `me`.`ccode`, `me`.`materials`, `me`.`uri`, `me`.`itype`, `me`.`more_subfields_xml`, `me`.`enumchron`, `me`.`copynumber`, `me`.`stocknumber`, `me`.`new_status`, `me`.`exclude_from_local_holds_priority` FROM `items` `me` WHERE ( `me`.`itemnumber` = ? )" with ParamValues: 0=1] at /usr/share/perl5/DBIx/Class/Storage/DBI.pm line 1836. error retrieving biblio 1 at /usr/share/koha/bin/migration_tools/rebuild_zebra.pl line 686. I understand this database error was previously affecting a different table and was addressed in bug 24986. https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24986 Looks like a patch is needed to cure this one as well. I am not a programmer so turning to the bug list for help. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 94

[Bug 26912] New: Expired staff accounts can still log in to Koha staff intranet
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '24

03 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26912 Bug ID: 26912 Summary: Expired staff accounts can still log in to Koha staff intranet Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal 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 We just discovered that staff accounts can be used for staff logins, SIP, API, etc even if they are expired. The question we don't have an answer to is; should this be allowed? We could prevent staff logins for expired accounts, or perhaps add a new 'enabled' column to explicitly enable/disable accounts from logging in to Koha. Right now, the only way to disable an account without deleting it is to remove user permissions, which may be non trivial if the account has complicated permissions and may need to be 'restored' in the future. What do you all think? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 25328] New: Date formatting from JS - Remove tz handling
by bugzilla-daemon＠bugs.koha-community.org 03 Jan '24

03 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25328 Bug ID: 25328 Summary: Date formatting from JS - Remove tz handling Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: agustinmoyano(a)theke.io Reporter: agustinmoyano(a)theke.io QA Contact: testopia(a)bugs.koha-community.org CC: jonathan.druart(a)bugs.koha-community.org, martin.renvoize(a)ptfs-europe.com, tomascohen(a)gmail.com Depends on: 24455, 24980 After some discussion, I now believe timezone handling in JS is redundant, and should be removed. Dates that comes from the API are already converted to the corresponding timezone with dt_from_string, so there is no need for a second conversion here. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24455 [Bug 24455] Date formatting from JS https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24980 [Bug 24980] Date formatting from JS - use timezone only with dates with offset -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 19616] New: Formatted Contents Note (Marc 21 505), subfield g isn' t visible in the OPAC
by bugzilla-daemon＠bugs.koha-community.org 02 Jan '24

02 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19616 Bug ID: 19616 Summary: Formatted Contents Note (Marc 21 505), subfield g isn't visible in the OPAC Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org The 505 field in Marc 21, Formatted Contents Note, includes subfield g "Miscellaneous information". According to the Marc 21 format for bibliographic data, it is used to record "volume, part, page numbering or other extent information such as dates". If you use it in Koha, this information isn't visible in the OPAC. -- You are receiving this mail because: You are watching all bug changes.

1 35