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

[Bug 33475] New: Remove Syndetics template variables from Auth.pm
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '23

10 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33475 Bug ID: 33475 Summary: Remove Syndetics template variables from Auth.pm 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: lucas(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org 593 SyndeticsClientCode => C4::Context->preference("SyndeticsClientCode"), 594 SyndeticsEnabled => C4::Context->preference("SyndeticsEnabled"), 595 SyndeticsCoverImages => C4::Context->preference("SyndeticsCoverImages"), 596 SyndeticsTOC => C4::Context->preference("SyndeticsTOC"), 597 SyndeticsSummary => C4::Context->preference("SyndeticsSummary"), 598 SyndeticsEditions => C4::Context->preference("SyndeticsEditions"), 599 SyndeticsExcerpt => C4::Context->preference("SyndeticsExcerpt"), 600 SyndeticsReviews => C4::Context->preference("SyndeticsReviews"), 601 SyndeticsAuthorNotes => C4::Context->preference("SyndeticsAuthorNotes"), 602 SyndeticsAwards => C4::Context->preference("SyndeticsAwards"), 603 SyndeticsSeries => C4::Context->preference("SyndeticsSeries"), 604 SyndeticsCoverImageSize => C4::Context->preference("SyndeticsCoverImageSize"), I don't think these need to be in Auth.pm anymore. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 33474] New: Don't create a notice for patrons without email when UseEmailReceipts is used
by bugzilla-daemon＠bugs.koha-community.org 10 Apr '23

10 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33474 Bug ID: 33474 Summary: Don't create a notice for patrons without email when UseEmailReceipts is used Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org With UseEmailReceipts set to "Send" it will always create an entry in the message_queue, even if the user has no email address. We should not create the notice, when the patron has no email. I am not sure about falling back to print since the those would probably just be handed out and not mailed to the patron. There is also already a print option in Accounting to create a printed receipt. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33469] New: Hacked by lord badut
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33469 Bug ID: 33469 Summary: Hacked by lord badut Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Bugzilla Assignee: jonathan.druart+koha(a)gmail.com Reporter: samuelnasib006(a)gmail.com Created attachment 149374 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149374&action=e… Retas web anda -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 33467] New: Hacked by lord badut
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33467 Bug ID: 33467 Summary: Hacked by lord badut Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: samuelnasib006(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 149372 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149372&action=e… Hacked By LORD BADUT Hacked by LORD BADUT -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 33468] New: Hacked by lord badut
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33468 Bug ID: 33468 Summary: Hacked by lord badut Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: samuelnasib006(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 149373 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=149373&action=e… Hacked By LORD BADUT -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 33461] New: Password reset should act like patron expiration when there are no notices available
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33461 Bug ID: 33461 Summary: Password reset should act like patron expiration when there are no notices available 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com A password reset sends an email to a patron when executed. The following should be considered: 1) We should allow other delivery methods 2) If a patron doesn't have a delivery method, we should be able to use a method like password expiration, but Koha should generate a code that is put in place of the password. The patron has to put in the code in order to change the password. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 33460] New: Standardize breadcrumb for labeled MARC view
by bugzilla-daemon＠bugs.koha-community.org 09 Apr '23

09 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33460 Bug ID: 33460 Summary: Standardize breadcrumb for labeled MARC view Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Depends on: 33131 The breadcrumbs for the labeled MARC view doesn't match the breadcrumbs for the other record views. Currently the breadcrumb reads: Home > Catalog > MARC details for Programming the Perl DBI / It should read: Home > Catalog > Programming the Perl DBI / > Labeled MARC details To see the labeled MARC view the viewLabeledMARC system preference needs to be activated. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33131 [Bug 33131] Use template wrapper for breadcrumbs: Catalog part 1 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 21255] New: memberetnry.pl is missing categories in the Category pull-down list
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '23

08 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21255 Bug ID: 21255 Summary: memberetnry.pl is missing categories in the Category pull-down list Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cnighswonger(a)foundations.edu QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com In some instances, when editing a patron, the Category pulldown under the "Library management" section is missing categories. I'm at a loss as to how to accurately describe the problem, but here goes: 1. The given patron's category shows up correctly on every other screen. 2. Navigating to the Patron Detail screen and selecting the edit option for Library use section results in the Modify Patron screen. 3. The heading on the Modify Patron screen displays the correct category. 4. However, the Category pulldown does not. 5. Furthermore, the pulldown does not even contain the correct category for the given patron. Doing a bit of looking around turned up a few things which may or may not be related. For the given patron: 1. The problem seems to be with the child category. 2. The Koha::Patron::Categories object may contain missing or incorrect category information. Here is a snip of the object returned for the 'C' category type by this line http://git.koha-community.org/gitweb/?p=koha.git;a=blob;f=members/memberent… 'attrs' => { 'bind' => [], 'join' => 'categories_branches', 'order_by' => [ 'categorycode' ], 'where' => { 'category_type' => 'C', 'categories_branches.branchcode' => [ 'JL', undef ] }, 'alias' => 'me' }, 3. The underlying data appears to be sound. 4. This was not a problem prior to upgrading a month ago. Unfortunately, I'm not sure what version this system was at prior to the upgrade. Maybe this will get the discussion started and someone with more knowledge of this area of the code can give some direction to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 7

[Bug 33458] New: Patron categories for specific libraries should be retained by other libraries
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '23

08 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33458 Bug ID: 33458 Summary: Patron categories for specific libraries should be retained by other libraries 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently you can set specific patron categories for specific libraries, or all. If we set them for specific libraries, that works well. What doesn't work is if the patron is edited by another library that doesn't have access to that particular category. If you edit a patron account that has a category that is not used by your library, the category will be changed to the top most category without warning. It would be preferred that if a patron is assigned a patron category that is not normally used by your library, that when editing, it would retain that category unless you change it. In other words, library limitations should only affect choosing those items (patron categories, shelving locations, or anything else that uses limitations). It shouldn't change it if you are updating a record. You should be allowed to change from it. But once you have changed from it, it shouldn't show, and you shouldn't be able to change back. This should probably be set for other library limitations too, but I specifically want to address patron categories in this bug. I think the simplest way to put this is, library limited items should show when in use and active on the record in question, but should not show when they aren't. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 33451] New: Password reset menu location
by bugzilla-daemon＠bugs.koha-community.org 08 Apr '23

08 Apr '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33451 Bug ID: 33451 Summary: Password reset menu location 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com For some reason we keep "Send password reset" under the more button. It seems more appropriate to replace the "Change password button" with a "Reset password", which also could include a dropdown option for the Change password action. Since staff should not typically enter a know or enter a patron password, resetting seems a more appropriate default action. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0