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

[Bug 9762] Log circulation overrides
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 Matthias Le Gac <matthias.le-gac(a)inlibro.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |matthias.le-gac(a)inlibro.com -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36449] New: Patron->store falls back to stored password when modifying patron
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36449 Bug ID: 36449 Summary: Patron->store falls back to stored password when modifying patron 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: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org At some point we added this in patron->store (ModMember-labeled part): # Password must be updated using $self->set_password $self->password($self_from_storage->password); I stumbled over that requirement in a custom script updating specific patron accounts. But we do allow to set the password in the AddMember part. Which feels inconsistent at the least.. But why do we silently(!) ignore a new password here? A warn might have been handy too ;) Couldnt we just add a call to set_password in store and perhaps add a param to not explicitly save it (when coming from store) or something like that? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21087] New: Patron's password is hashed twice when the object is saved
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21087 Bug ID: 21087 Summary: Patron's password is hashed twice when the object is saved Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 20287 When a patron is edited (reading the code at least using patron batch modification), the password is lost. Prior to bug 20287 ModMember took the $hash of modification, and '****' was a trick to not update the password (when coming from memberentry). The same trick has been reused for the move of ModMember to Koha::Patron->store, but then the following code will modify the password of the patron: my $password = 'password'; $patron->password($password)->store; $patron->surname('xxx')->store; => User is not longer able to login with 'password' Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20287 [Bug 20287] Move AddMember and ModMember to Koha::Patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 9886] ParseLetter removes too often punctuation characters from fields
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9886 Jonathan Druart <jonathan.druart(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |https://bugs.koha-community | |.org/bugzilla3/show_bug.cgi | |?id=36451 -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36446] New: Library specific shelving locations disappear when logged in
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36446 Bug ID: 36446 Summary: Library specific shelving locations disappear when logged in Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org If a shelving location is associated with specific branches, when you go to advanced search in the OPAC, and then on the shelving location tab, you can see all shelving locations when not logged in, but if you are logged in, and your branch is not associated with that shelving location, it disappears from the list. Should there be a setting to determine how this works? It seems that shelving locations should not disappear from this list at all, especially if you are allowed to borrow from that library. For the sake of simplicity, I think that all shelving locations should show here, regardless of what branch is associated with it. If there are borrowing or hold restrictions, you will find out at the appropriate place. But this should not act in this manner, in my opinion. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 36445] New: Removing email address has no effect on clubs that require an email address
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36445 Bug ID: 36445 Summary: Removing email address has no effect on clubs that require an email address Change sponsored?: --- Product: Koha Version: unspecified 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 If a patron is enrolled in a club that requires an email address, and then the email address is completely remove from the patron account, nothing changes with the club. There should be some kind of warning that the patron is enrolled in clubs that require an email address. Maybe the clubs tab needs to turn red, and then a message next to enrolled clubs that require an email address needs to have text in red next to it saying "Email address required". -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 0

[Bug 34291] New: Clubs requiring email just don't show if there is no email
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34291 Bug ID: 34291 Summary: Clubs requiring email just don't show if there is no email 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 We were scratching our heads over this one. We were wondering why some clubs were not showing for some patrons, and showing for others. It is because the club is setup to require an email address. Which makes sense. But instead of just hiding the clubs, could they be greyed out or disabled with a red reminder that it requires an email address? This would explain things a lot better. Or, at the very least, if any clubs are hidden, could there at least be a red warning at the top of the clubs that some are hidden because they require an email address? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 11300] Add a new authority linker which searches for authority links on a Z39.50 server.
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11300 Maude <maude.boudreau(a)collecto.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |maude.boudreau(a)collecto.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 9762] Log circulation overrides
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 Lucas Gass <lucas(a)bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Failed QA --- Comment #12 from Lucas Gass <lucas(a)bywatersolutions.com> --- Lots of issues here. 1. renew.pl now fails with this error: Could not compile /kohadevbox/koha/circ/renew.pl: Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) at /kohadevbox/koha/circ/renew.pl line 67. 2. Looks like some debugging code is leftover 3. request.pl has a whole block of code commented out starting with: # elsif ( C4::Context->preference('AllowHoldPolicyOverride') ){ 4. Why remove the check for "unless( $skip_record_index )" in AddRenewal? I think there are times when we want to skip indexing. 5. FAIL C4/Circulation.pm FAIL pod coverage POD is missing for CanBookBeReturned 6. FAIL circ/renew.pl WARN tidiness The file is less tidy than before (bad/messy lines before: 28, now: 44) FAIL valid Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) Global symbol "$issue" requires explicit package name (did you forget to declare "my $issue"?) Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) Global symbol "$borrower" requires explicit package name (did you forget to declare "my $borrower"?) circ/renew.pl had compilation errors. 7. Changes to CanBookBeIssued and AddRenewal probably need test coverage. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 9762] Log circulation overrides
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9762 --- Comment #11 from Matthias Le Gac <matthias.le-gac(a)inlibro.com> --- Created attachment 164022 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=164022&action=e… Bug 9762: fix log for test 10 13 14 15 16 17 To test: --After each step, a message will be displayed in the action_logs table and in Tools > Log viewer -- Circulation -- Checking out 1) Check out an item that is age-restricted (AgeRestrictionOverride syspref) 2) Check out an item that has a “not for loan” status (AllowNotForLoanOverride syspref) 3) Check out an item that has a “lost” status (IssueLostItem syspref) 4) Check out an item to a patron who has reached the checkout limit (AllowTooManyOverride syspref) 5) Check out an item to a patron who is not allowed to borrow this item type 6) Check out an item to a patron who has unpaid fines (AllFinesNeedOverride and/or AllowFineOverride + noissuescharge sysprefs) 7) Check out an item on hold for someone else 8) Check out an item on hold ready for pickup by someone else 9) Check out an item already checked out to someone else (AutoReturnCheckedOutItems syspref) 10) Check out to a patron who has restrictions Circulation -- Checking in 11) Ignore a hold upon check in 12) Ignore a hold and transfer upon check in Circulation – Renewing 13) Renew an item on hold for someone else (AllowRenewalOnHoldOverride syspref) 14) Renew an item that has reached the maximum number of renewals (AllowRenewalLimitOverride syspref) Holds 15) Place a hold for a patron who is not allowed to place this item type on hold (AllowHoldPolicyOverride syspref) 16) Place a hold for a patron who has reached the maximum number of holds 17) Place an item-level hold when rules dictate that this is not allowed (In circulation rules put "On shelf holds allowed" to "If any unavailable") -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 0