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

[Bug 3492] Move hold fee setting into circulation rules
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3492 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Set hold fees by item type |Move hold fee setting into |and charge when hold placed |circulation rules --- Comment #14 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I have updated the bug description per the discussion below. HoldFeeMode already allows to charge when placing a hold. -- You are receiving this mail because: You are the assignee for the bug. You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3796] Place a hold on a specific copy allows impossible items
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3796 --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Christopher Brannon from comment #5) > We don't have specifics yet. All we have is the evidence left the table. > > I think that there should be a check somewhere...a cron job, or something, > that checks the validity of the reserves table. Particularly between the > item number and bib number. And perhaps against the patron account. There > are two problems evident: > > 1) Mismatched item and bib numbers in the reserves table. > 2) Reserves showing in the reserves table, and not showing in the patron > account. Most likely because of issue 1. > > Is it necessary to have a bib number in the reserves table when the item > number is recorded for an item level hold? Seems redundant if the bib > number is in the items table. That would be the simplest remedy for this > issue. So, rather than using the bib number in the reserves table for any > holds functions, it could be referenced from the items table. > > Otherwise, we might need a checkpoint to verify accuracy. > > As I said, we don't have an answer as to how this is happening. I can think > of a few ways it might happen, but I don't think one of them is the case, > since it happened to a couple of items with the same patron. > > One way it could happen is that a patron is reconstructing the URL manually > and blending mismatched info. > > The second way is that a hold is placed on an item. The item record is then > turned into a different item and attached to a different bib. OR better > yet, an item is created and accidently attached to the wrong bib, and after > the hold is placed, the item is moved to the correct bib. > > It seems that maybe when items are moved from one bib to another, a check > should take place to verify any possible holds in the reserves table. > > I don't know if this helps, but that's my two cents. > > Christopher Hi Christopher, are this still issues you see in current versions? Is there any step by step that we could use to reproduce the issue? -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 3831] Add a warning/hint when FA framework is missing
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3831 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt(a)gmail.com |koha-bugs(a)lists.koha-commun | |ity.org -- You are receiving this mail because: You are the QA Contact for the bug. You are the assignee for the bug. You are watching all bug changes.

1 0

[Bug 3831] Add a warning/hint when FA framework is missing
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3831 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |NEW -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 3831] Add a warning/hint when FA framework is missing
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3831 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Fast Add Framework Should |Add a warning/hint when FA |not be Deletable |framework is missing Status|In Discussion |ASSIGNED --- Comment #12 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- Trying to free this from In discussion by agreeing with the last 2 comments :) -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4031] Ability to turn off search history for users not logged in
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4031 --- Comment #6 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- (In reply to Katrin Fischer from comment #5) > We have just had a library 'complaining' about the fact that the anon > history is added to the patron account on log in. This is especially a > problem if the library offers computers for searching the OPAC in the > library that get frequented by a lot of different users. > > I think this configuration option Matts proposed would be really helpful > there. We also have LoadSearchHistoryToTheFirstLoggedUser now that allows to determine what happens with the anonymous searches once a patron logs in. But it's still possible to see what other users searched for when you are using a public computer. So it might still be nice to have the option to limit search history logging to logged in users. -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4034] Checking out an item on hold for that patron (but not waiting) results in incorrect message
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4034 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #5 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- > ---- Reported by oleonard(a)myacpl.org 2010-01-11 15:09:33 ---- > > Steps to reproduce: > > - Item is on hold for a patron, but item has not been made waiting > - Check the item out to that patron > > An message will appear: "Please Confirm Checkout * Item is on reserve for > [this patron]" > > The message implies that you're checking out something that is on hold for a > *different* patron. This works nicely now: * No confirmation message * Hold is marked as filled/resolved -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4040] Placing a hold on an item while it is in transit results in duplicate dialogs upon check-in
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4040 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED -- You are receiving this mail because: You are the QA Contact for the bug. You are watching all bug changes.

1 0

[Bug 4040] Placing a hold on an item while it is in transit results in duplicate dialogs upon check-in
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4040 --- Comment #12 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- I tried testing this (hopefully correctly). There is only one dialog now consistently that asks for "confirm hold and transfer". I believe the current behaviour is correct, please reopen if I missed something! -- You are receiving this mail because: You are watching all bug changes. You are the QA Contact for the bug.

1 0

[Bug 4455] Language specific order claims notices
by bugzilla-daemon＠bugs.koha-community.org 08 Jan '23

08 Jan '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=4455 Katrin Fischer <katrin.fischer(a)bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Language Specific Claims |Language specific order |Notices |claims notices --- Comment #1 from Katrin Fischer <katrin.fischer(a)bsz-bw.de> --- What might be missing here might be a preferred language setting for the vendor. Or alternatively maybe a setting for the notice template to use? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug. You are the QA Contact for the bug.

1 0