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

[Bug 35821] New: Add option to log a run of export_records.pl to the Koha cron log
by bugzilla-daemon＠bugs.koha-community.org 16 Jan '24

16 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35821 Bug ID: 35821 Summary: Add option to log a run of export_records.pl to the Koha cron log 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: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Libraries often have export jobs scheduled to send MARC records here and there. It would be cool if we could have the cron job optionally log it's run to the action_logs via the cron log. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 26071] New: Allow to configure fields not to be copied when using "Edit as new (duplicate)" in cataloging
by bugzilla-daemon＠bugs.koha-community.org 15 Jan '24

15 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26071 Bug ID: 26071 Summary: Allow to configure fields not to be copied when using "Edit as new (duplicate)" in cataloging Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When duplicating a record for example for cataloging a newer edition an exact duplicate of the record is created. In some cases it would be nice if you could define fields that should be emptied out when duplicating, similar to what we can do when duplicating subscriptions (SubscriptionDuplicateDroppedInput). The use case here would be to drop 001 when copying, so no duplicate IDs are added to the catalog. The field is marked mandatory so then the cataloger will be reminded to fill it in. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 35809] New: Catalog statistics should use items.deleted_on instead of items.timestamp
by bugzilla-daemon＠bugs.koha-community.org 14 Jan '24

14 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35809 Bug ID: 35809 Summary: Catalog statistics should use items.deleted_on instead of items.timestamp 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org We didn't have the deleted date for items in a separate field in the past, but the timestamp turned out not to be reliable with other updates on the table updating it. So we should use deleted_on on for reporting now. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35806] New: Patron statistics report should treat sort 1 and sort 2 the same
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35806 Bug ID: 35806 Summary: Patron statistics report should treat sort 1 and sort 2 the same 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org For some unknown reason we treat the sort 1 and sort 2 search fields in the patron statistics report differently: $req = $dbh->prepare("SELECT authorised_value,lib FROM authorised_values WHERE category='Bsort1' ORDER BY lib"); $req->execute; $template->param( SORT1_LOOP => $req->fetchall_arrayref({})); $req = $dbh->prepare("SELECT DISTINCTROW sort2 AS value FROM borrowers WHERE sort2 IS NOT NULL AND sort2 <> '' ORDER BY sort2 LIMIT 200"); # More than 200 items in a dropdown is not going to be useful anyway, and w/ 50,000 patrons we can destroy DB performance. $req->execute; $template->param( SORT2_LOOP => $req->fetchall_arrayref({})); For sort 1 we check for the authorised value, for the sort 2 we check for values from the database. For each we should check first if the field is linked to a database value and if not, we can create a list from the database. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 34926] New: BIBLIO_ALREADY_ISSUED statement missing in circulation_batch_checkouts.tt
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34926 Bug ID: 34926 Summary: BIBLIO_ALREADY_ISSUED statement missing in circulation_batch_checkouts.tt Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: marx.mr(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In circulation.tt the BIBLIO_ALREADY_ISSUED statement displays the following message: "Patron has already checked out another item from this record." This is missing in circulation_batch_checkouts.tt and the information is empty. The path is koha-tmpl/intranet-tmpl/prog/en/modules/circ/ -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 34935] New: ERM - "Agreement user" not translatable
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34935 Bug ID: 34935 Summary: ERM - "Agreement user" not translatable Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: caroline.cyr-la-rose(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr When adding an agreement in the ERM module, you can add users linked to that agreement. For each new user, there is a heading "Agreement user 1", "Agreement user 2", etc. This heading doesn't seem to be translatable. The only "Agreement user" I found in the po files is "Agreement user %s is missing a user". To get there: 1. Enable ERMModule 2. Go to ERM > Agreements > New agreement > Add new user --> A new heading says "Agreement user 1 Remove this user" 3. Update the po files gulp po:update --lang fr-CA 4. Search the po files for "Agreement user" grep "Agreement user" misc/translator/po/fr-CA* --> The string is not in the po files -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 35804] New: Distinction between future holds and suspended holds
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35804 Bug ID: 35804 Summary: Distinction between future holds and suspended holds Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Why are holds scheduled for a future date treated differently from suspended holds? I think to minimize confusion for setting the hold, you could just select a date in the future as you do now, but when you do, it could just place the hold and suspend it for that future date. This would allow the patron to unsuspend the hold and let it be active now if they change their mind. As is, if you set a hold in the future, you can't change it. You have to delete it and start over. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 35803] New: Scheduled holds (future) should be styled differently on request.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35803 Bug ID: 35803 Summary: Scheduled holds (future) should be styled differently on request.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Like the changes made in https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25856, holds scheduled in the future should also have a class that allows you to make these stand out from the others. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33257] New: Suspended holds should be styled differently on moremember.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33257 Bug ID: 33257 Summary: Suspended holds should be styled differently on moremember.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Although suspended holds are labeled on moremember.pl it would be nice to be able to style them so that they are more obvious. See bug #25856 where the patch added a suspend class to the tr's for suspended holds. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 33258] New: Suspended holds should be styled differently on circulation.pl
by bugzilla-daemon＠bugs.koha-community.org 13 Jan '24

13 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33258 Bug ID: 33258 Summary: Suspended holds should be styled differently on circulation.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: barbara.johnson(a)bedfordtx.gov QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Although suspended holds are labeled on circulation.pl it would be nice to be able to style them so that they are more obvious. See bug #25856 where the patch added a suspend class to the tr's for suspended holds. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3