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

[Bug 35681] New: Add support for colored messages in the output of updatedatabase
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35681 Bug ID: 35681 Summary: Add support for colored messages in the output of updatedatabase 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com We could use Term::ANSIColor in our database revisions to aid in highlighting different outputs, but in doing so we introduce escape sequences that look 'nasty' in the browser representation. We should add support for those sequences, allowing the same end user experience via browser or terminal. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 78

[Bug 18086] New: overduerules table is lacking foreign key constraints
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18086 Bug ID: 18086 Summary: overduerules table is lacking foreign key constraints Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation 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 The overduerules table has no foreign key constraints to any for the related tables. The columns for branchcode, categorycode, letter1, letter2, and letter3 should all be foreign keys. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 101

[Bug 16698] New: UpdateItemLocationOnCheckin preference needs a gui editor
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16698 Bug ID: 16698 Summary: UpdateItemLocationOnCheckin preference needs a gui editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 14576 adds a new syspref that accepts YAML for determining how the rules are applied. While there are other prefs accepting values in the same way, we should not expect users to understand YAML text formatting and should offer an easier option for entering the data We should decide on a best practice here for adding these guis. One option is to add pages on admin, however, I think this could get overwhelming the more sysprefs that use this method. I would propose adding a popup editor that will allow for easy entry, this editor will populate the syspref value so that advanced users can still access directly. Welcome to hear other thoughts, will proceed as proposed until then. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 33540] New: Add death date for deceased patron
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33540 Bug ID: 33540 Summary: Add death date for deceased patron Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: giuseppe.angilella(a)ct.infn.it QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When a patron dies, one shouldn't simply remove the patron from the database, in order to keep track of the patron's past circulation history. However, setting the expiration date to the patron's death date doesn't prevent the system from increasing the patron's age (indefinitely, as time passes), which is then displayed in the patron's details. I would then suggest to introduce some "death_date" additional field to the patrons table, and modify moremember.pl to compute the final age using death_date rather than the current (today's) date, whenever death_date is nonempty. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 34540] New: Unimarc Default framework
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34540 Bug ID: 34540 Summary: Unimarc Default framework Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: Igor.A.Sychev(a)mail.ru QA Contact: testopia(a)bugs.koha-community.org Unimarc Default framework When saving a record, the message: Tag 600 subfield a Entry Element in tab 6 Tag 601 subfield a Entry Element in tab 6 In Unimarc fields 600 and 601 are optional. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 18533] New: MARC::Record->encoding does not handle UNIMARC records
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18533 Bug ID: 18533 Summary: MARC::Record->encoding does not handle UNIMARC records Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 18152 Regarding bug 18152 MARC::Record->encoding should not be called directly from our codebase. C4::Charset::SetMarcUnicodeFlag should call MARC::Record->encoding for MARC21 and NORMARC but does the UNIMARC trick for UNIMARC records. It seems that MARC::Record->encoding calls should be replaced with C4::Charset::SetMarcUnicodeFlag everywhere. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18152 [Bug 18152] UNIMARC bib records imported with invalid 'a' char in label pos.9 -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 32906] New: Make 'Replace record via Z3950/SRU' buttons in authorities work consistently
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '24

07 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32906 Bug ID: 32906 Summary: Make 'Replace record via Z3950/SRU' buttons in authorities work consistently 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: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 29173 Bug 29173 implemented search pre-fill for the Replace via Z3950 search form from the authority detail page, but it did so in a very different, and MARC21 specific, way from the same button on the 'Edit authority' page. On the edit authority page we extract the pre-fill terms from the current page and pass them as URI parameters to the search pop-over form. I think we could take a similar approach on the detail display page and perhaps even make the feature work for both MARC21 and UNIMARC in this way? Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29173 [Bug 29173] Button "replace authority record via Z39/50/SRU" doesn't pre-fill -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 32920] New: ES indexer should gracefully handle a bad bib record when reindexing after a batch modification
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '24

06 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32920 Bug ID: 32920 Summary: ES indexer should gracefully handle a bad bib record when reindexing after a batch modification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: emily.lamancusa(a)montgomerycountymd.gov When Elasticsearch reindexes after a batch modification, if one of the modified biblio records contains invalid data, the "Update Elasticsearch Index" job will fail without updating the search indexing for any of the modified records. When reindexing multiple records at once, an error with one record should not prevent the others from being reindexed correctly. To reproduce: 1. Set SearchEngine system preference to 'Elasticsearch' 2. Find or produce a biblio record that contains invalid data (in KTD's sample data, biblionumber 369 works for this) 3. Confirm that the biblio record detail page in the staff interface displays an invalid data error 4. Generate a barcode file that includes items attached to this biblio as well as other items 5. Perform a batch item modification 6. Open the job list. Note "Finished" status for batch item mod job, and "Failed" status for Update Elasticsearch index job 7. Find the modified records via catalog search. Note that none of the modified items display the updated information in the catalog search. I reproduced this error on KTD, by doing a batch edit on all items with publication date 198_ In case it's useful, error message from the failed job: ^ at /kohadevbox/koha/Koha/Biblio/Metadata.pm line 114. DEBUG - Update of elastic index failed with: Invalid data, cannot decode metadata object (biblio_metadata.id=368, biblionumber=369, format=marcxml, schema=MARC21, decoding_error=':8: parser error : PCDATA invalid Char value 31 <controlfield tag="001">00aD000015937</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :9: parser error : PCDATA invalid Char value 31 <controlfield tag="004">00satmrnu0</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^ :10: parser error : PCDATA invalid Char value 31 <controlfield tag="008">00ar19881981bdkldan</controlfield> ^') -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 36583] New: MEMBERSHIP_RENEWED message for manual renewals
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '24

06 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36583 Bug ID: 36583 Summary: MEMBERSHIP_RENEWED message for manual renewals Change sponsored?: --- Product: Koha Version: 23.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Libraries who require in-person patron account renewals (so that they can confirm contact information etc.) may also want to send a record of the renewal to their patrons, so it would be nice if the new MEMBERSHIP_RENEWED notice coming with bug 28688 could be sent for manual patron account renewals, not just for automatic account renewals via the membership_expiry.pl cron. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 36514] New: The "kick_out" in auth should return an anonymous session instead of no session
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '24

06 Nov '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36514 Bug ID: 36514 Summary: The "kick_out" in auth should return an anonymous session instead of no session 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org At the moment, when we "kick_out" of the self-checkout or the self-checkin, we send a CGISESSID cookie with an empty value and force the web app to render opac-auth.tt However, this doesn't really make sense. If the user just reloads the page again, they'll see the real template. And if you want to link to the self-registration from the self-checkout (say in a new tab), you'll want to see the real template instead of a login screen. -- In theory, it shouldn't be too hard to do this. We'll just want to create an anonymous session and return the actual requested template. This isn't a top priority for me at the moment, but I do have a library interested in this, so I might find myself working on this... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2