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

[Bug 33844] New: item->is_denied_renewal should validate fields from associated pref
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '23

18 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33844 Bug ID: 33844 Summary: item->is_denied_renewal should validate fields from associated pref 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 See bug 32478. You could even add a field 'delete' in the pref. This is really bad. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 32478] New: Remove Koha::Config::SysPref->find since bypasses cache
by bugzilla-daemon＠bugs.koha-community.org 18 Jul '23

18 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32478 Bug ID: 32478 Summary: Remove Koha::Config::SysPref->find since bypasses cache 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: glasklas(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Using Koha::Config::SysPrefs->find('UpdateItemLocationOnCheckin')->get_yaml_pref_hash() to retrieve yaml sysprefs will bypass caching negating the very minor performance gain per call get_yaml_pref_hash was meant to achieve since it in some cases is being called repeatedly a very large number of times. Replacing it with C4::Context->yaml_preference('ItemsDeniedRenewal') will utilize the syspref cache and also not support a very small (not even valid) subset of YAML. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 45

[Bug 34049] New: Keep track of fund amount modification
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '23

17 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34049 Bug ID: 34049 Summary: Keep track of fund amount modification Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: mathsabypro(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be interesting to add a function to historicize funds amount, keeping track of their modification. Some other ILS have this feature. Ex : A fund is created with an amount of 10000. After X months, the head librarian decides to reduce it to 8000, with a note explaining why ; and an email is automatically send to the owner and users of the fund In my library this kind of modification is not rare, and it is hard to keep track of these changes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 33963] New: Remove C4::BackgroundJob
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '23

17 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33963 Bug ID: 33963 Summary: Remove C4::BackgroundJob Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 33962 No more occurrences! Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33962 [Bug 33962] Remove C4::BackgroundJob from process_koc -- You are receiving this mail because: You are watching all bug changes.

1 13

[Bug 33962] New: Remove C4::BackgroundJob from process_koc
by bugzilla-daemon＠bugs.koha-community.org 17 Jul '23

17 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33962 Bug ID: 33962 Summary: Remove C4::BackgroundJob from process_koc Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart+koha(a)gmail.com Reporter: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Depends on: 2608 The last occurrence of C4::BackgroundJob is in process_koc.pl that is used to upload a file. Added by bug 2608 (15 years ago), I think it does not longer make sense as networks are faster, and we should not expect big koc files to be uploaded. If there are complains we will move it to Koha::BackgroundJob. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=2608 [Bug 2608] offline circ processing of large KOC files can time out -- You are receiving this mail because: You are watching all bug changes.

1 11

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

16 Jul '23

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 7

[Bug 28618] New: Move t/lib modules to lib/Koha/Test
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '23

16 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28618 Bug ID: 28618 Summary: Move t/lib modules to lib/Koha/Test 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: jonathan.druart+koha(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 29258] New: Add a value builder for filling in the vendor id in the item form
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '23

16 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29258 Bug ID: 29258 Summary: Add a value builder for filling in the vendor id in the item form Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When using the acquisitions module the vendor field in the item form (item.booksellerid) will be filled with the id of the vendor record. Sometimes, there are items that will still be catalogued outside the acquisitions module, like older acquisitions or donations. To not have a mix of "string" vendor names and ids in the item field, it would be nice if we have a value builder/cataloging plugin that allowed to search for vendors and added the id to the form when editing/adding items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34173] New: Imported items do not require home/holding branches, causing uneditable item records
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '23

16 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34173 Bug ID: 34173 Summary: Imported items do not require home/holding branches, causing uneditable item records Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: wizzyrea(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl In some configurations, importing items through the stage/import workflow causes items to be created that have no home or holding branch. The mandatory settings are not enforced through the frameworks, so these items can come in without a home and holding branch, leading to no staff having the ability to edit these records. Fixes must be made in the database to update these items. For some libraries adding a marc modification template to add the branch could be a workaround. For systems with many branches and tightly controlled rules about who can edit items, this bug can lead to uneditable items. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 22820] New: Display 830 series information when there is no 490 tag (MARC21)
by bugzilla-daemon＠bugs.koha-community.org 16 Jul '23

16 Jul '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22820 Bug ID: 22820 Summary: Display 830 series information when there is no 490 tag (MARC21) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: joy(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- Currently, the 830 tag will display only when the 490 tag is present and indicator 1=1. It is possible to have a valid 830 tag without a corresponding 490 tag. We need to include logic in the stylesheet to display the 830 when no 490 is found. -- You are receiving this mail because: You are watching all bug changes.

1 22