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

[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

[Bug 35587] New: Items lose their lost status when check-in triggers a transfer even though BlockReturnOfLostItems is enabled
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '24

12 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35587 Bug ID: 35587 Summary: Items lose their lost status when check-in triggers a transfer even though BlockReturnOfLostItems is enabled Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: aleisha(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com BlockReturnOfLostItems when enabled should mean lost status are retained when an item is checked in. If the check-in triggers a transfer to another library, the lost status is removed. --> BUG -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 25

[Bug 34900] New: The translation of the string "The " should depend on context
by bugzilla-daemon＠bugs.koha-community.org 12 Jan '24

12 Jan '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34900 Bug ID: 34900 Summary: The translation of the string "The " should depend on context Change sponsored?: --- Product: Koha Version: 23.05 Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr The string "The " is present - 22 times (in 23.05 version) in koha-tmpl/intranet-tmpl/prog/en/modules/about.tt for different uses : "The [...] Athens County Public Libraries" => singular "The [...] jQuery Validation Plugin" "The [...] controls for column visiblity in DataTables" => plural etc - and 1 time in koha-tmpl/intranet-tmpl/prog/en/modules/members/members-update.tt in that string : "The [strong]Gone no address[strong] flag is set for this patron." In Pootle, all these occurences are grouped. This is a nonsense because in many languages "The" must be translated by different articles (ex in french le / la / les) , and for the last example, in french we must translate "the" by "le flag" Can it be fixed, in Pootle or in Koha's code? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 40