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

[Bug 27834] New: CircControl syspref is used wrong in TooMany function C4::Circulation
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27834 Bug ID: 27834 Summary: CircControl syspref is used wrong in TooMany function C4::Circulation 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: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com The CircControl syspref description says > Use the checkout and fines rules of > PickupLibrary: the library you are logged in at. > PatronLibrary: the library the patron is from. > ItemHomeLibrary: the library the item is from. This is mostly true but there is one exception in the TooMany function where it actually doesn't just change which libraries rules are used but how the the calculation is performed. With PatronLibrary set the behaviour is as expected by reading the syspref description. However with the setting PickupLibrary the behaviour changes now, instead of just using the rules of the pickup library we also only take into account the loans in the pickup library when calculating whether we are over the checkout limit or not. The same happens with ItemHomeLibrary where we instead calculate the patron's checkouts in the home library of the item being checked out. We should really try to fix this either by a) showing that ItemHomeLibrary and PickupLibrary is unacceptable and no one actually wants that, that would allow then making the behaviour similar as what it is to PatronLibrary (so just selecting the right circ rule instead of changing calculation method). b) Provide a new syspref for changing the calcutation method when PickupLibrary or ItemHomeLibrary CircControl values are used, and set it on upgrade enabled as default. Ps. svc/letters/preview might use CirControl wrongly as well, I'm not 100% I didn't quite understand but as for other usages of CircControl syspref I grepped where it was used and it correctly only changed the circ rules to be used instead of changing behaviour. So in addition to TooMany we might have to do some changes to svc/letters/preview if it turns out it changes behaviour as well. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 50

[Bug 23849] New: Update the list of sysprefs to share with Hea
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23849 Bug ID: 23849 Summary: Update the list of sysprefs to share with Hea Change sponsored?: --- Product: Koha Version: unspecified 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: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org We have a lot of sysprefs that are not recorded in Hea. We lack a process to keep the list up-to-date. We are going to have an updated list for 19.11. For next releases it should be a new post release task (https://wiki.koha-community.org/wiki/Post_major_release_tasks) This bug report could be reused for the next releases. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 85

[Bug 29392] New: Add plugin hooks before merging biblios or authorities
by bugzilla-daemon＠bugs.koha-community.org 28 Oct '26

28 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29392 Bug ID: 29392 Summary: Add plugin hooks before merging biblios or authorities Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org For when we want to modify the final record of a merge operation -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 29099] New: Add support for item bundles in the inventory tool
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29099 Bug ID: 29099 Summary: Add support for item bundles in the inventory tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com I chose to split out the inventory tool additions from the bundles bug.. that bug was already big enough ;) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 23909] New: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23909 Bug ID: 23909 Summary: SCO allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Self checkout Assignee: koha-bugs(a)lists.koha-community.org Reporter: joonas.kylmala(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org Currently SCO module allows to check out items with Waiting state if AllowItemsOnHoldCheckoutSCO is enabeld. Waiting items should not be able to be checked out unless librarian overrides because the notifications of an item available for pickup might have already been sent. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 75

[Bug 31092] New: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31092 Bug ID: 31092 Summary: Upon importing batch records, if a full MARC record is found, only append the items; do not overlay a full MARC record Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: balestrieri(a)monterey.org QA Contact: testopia(a)bugs.koha-community.org When receiving items from our vendors, the full MARC records are sent in batches for import. We would like the ability to have koha only overlay our brief "on order" records that already exist in the system, not our full records already in our system. Currently, the only choice is to overlay ALL or NO records (choices are "Replace, Add, or Ignore") and to append the items, depending on the matching rule used (most users currently match on ISBN when importing books, audiobooks). Apparently, other ils systems have the ability to determine which existing records are brief and which existing records are full, and you can choose to only overlay the brief MARC records, leaving the full MARC records in tact, appending only the items. I understand the definitive markers are in the leader of the marc record. The leader will show the level of marc record it is. Most loaders will have a function to put this as one of the criteria. An example of an incoming Leader: =LDR 01429pam a2200385 i 4500 Position 17 is the encoding level. The above encoding level is blank, so it is a full level record. Encoding levels: Blank - full level record 1 - full level record 2 – less-than-full level record 3 – less than full level record 4 - less than full level record 5 – less than full level record 6 - less than full level record 7 – less than full level record 8 – less than full level (this is a prepublication record) It would be most convenient if koha would have an internal matching rule that allows for the user to overlay only existing records where levels 2-8 are in position 17 on the MARCs, ignoring any records with a "blank" or "1" in position 17 on existing MARCS, with the ability to still append all items. Right now, many of us in aquisitions need to create separate vendor accounts to order "added/existing" items only to avoid the constant overlaying of full MARC records in koha. We know any items arriving from these accounts already have full records in our system, so the vendor does not send full MARCs for any items ordered from these accounts. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 29769] New: Claim return status cannot be changed without checking item in
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29769 Bug ID: 29769 Summary: Claim return status cannot be changed without checking item in Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: bwsdonna(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com With the addition of bug 24279, libraries can no longer change the status of a claim return without checking the item in, which is not a desired behavior. Example: a library sets an item to claims return, looks for the item for three months per policy, item is not found, status needs to be changed from Claim to Lost so the patron is billed for the item. In this scenario, the item should not be checked in to clear the claim status. Marking the claim as resolved does not allow the status to be changed either. Perhaps this could be a setting with Claims Return system preferences as to whether staff are permitted to change the claim/lost status of an item from moredetail.pl? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 31099] New: [DOCS] Export data tool - setup so database and configuration data can be downloaded
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31099 Bug ID: 31099 Summary: [DOCS] Export data tool - setup so database and configuration data can be downloaded Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: david(a)davidnind.com QA Contact: testopia(a)bugs.koha-community.org Add information to the manual on how to set up Tools > Export data so that the database and configuration backups are enabled and shown. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 31256] New: Circ rules batch modification
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31256 Bug ID: 31256 Summary: Circ rules batch modification Change sponsored?: --- Product: Koha Version: 21.11 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 Wouldn't it be nice if you could batch modify rules? Like, I have to set a hard due date for schools each year. Instead of modify each rule individually, it would be great if I could specify all libraries, or specific ones, all rules under that or specific ones, and what I would change. There are times when we have to change the fines to everything, or change the holds to many rules, etc. This would make this job so much easier. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16

[Bug 33501] New: Cashup amount should be configurable
by bugzilla-daemon＠bugs.koha-community.org 27 Oct '26

27 Oct '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33501 Bug ID: 33501 Summary: Cashup amount should be configurable Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org It seems the Cashup summary only accounts for the cash payment type. We have a check payment type that should also be included. Am I missing a configuration somewhere, or do we need some way to define what should be included in the summary and intake balance? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 65