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

[Bug 31557] New: Hold queue/home vs. holding library/transport cost matrix complications
by bugzilla-daemon＠bugs.koha-community.org 02 Apr '26

02 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31557 Bug ID: 31557 Summary: Hold queue/home vs. holding library/transport cost matrix complications 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: sbrown(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be helpful if build_holds_queue.pl either 1) checked items' holding libraries in addition to home when items float, or 2) used the Transport Cost Matrix instead when systems have it enabled. Using home library only/first results in higher 'costs' and in holds being filled more slowly than necessary, and can be confusing for libraries. Home/holding: If I understand correctly, build_holds_queue.pl looks for items whose home library matches the hold's pickup library (plus accounting for any preferences set in StaticHoldsQueueWeight/HoldsQueueSkipClosed/RandomizeHoldsQueueWeight). For example, in a system where items float, a hold to be picked up at West library has the following items: Item 1: Home library West, holding library East Item 2: Home library West, holding library West Item 3: Home library North, holding library West If build_holds_queue.pl sees Item 1 first, it will be placed on East's queue to send to West even though Item 2 is already at West and could fill the hold more efficiently. Then since the Transport Cost Matrix is only consulted if no available items have a home library matching the hold's pickup library, holds are filled in a more 'expensive' way than libraries may expect. Using the Transport Cost Matrix directly would address this. For example, in a system where items float and a hold is to be picked up at South: Item 1: Home library East, holding library South Item 2: Home library West, holding library West Item 3: Home library South, holding library West build_holds_queue.pl will see that Item 3 has a home library matching the pickup library and will place it on West's queue to send to South. If build_holds_queue.pl consulted the Transport Cost Matrix, Item 1 would be placed on South's queue with no transfer necessary. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 30

[Bug 24125] New: Deleting an authority clears the record heading
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '26

01 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=24125 Bug ID: 24125 Summary: Deleting an authority clears the record heading Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: MARC Authority data support Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org To recreate: 1 - Find a record with an author linked to an authority 2 - Get that authority number 3 - Browse to tools->batch record deletion 4 - Select authorities and enter that authority id 5 - Delete the authority 6 - View the record, the 100 field has been cleared -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 22

[Bug 33353] New: Add compatibility with Elasticsearch 8
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '26

01 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33353 Bug ID: 33353 Summary: Add compatibility with Elasticsearch 8 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching - Elasticsearch Assignee: koha-bugs(a)lists.koha-community.org Reporter: julian.maurice(a)biblibre.com Indexation does not work with Elasticsearch 8 because it removed the support of types. https://www.elastic.co/guide/en/elasticsearch/reference/7.17/removal-of-typ… -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 44

[Bug 33965] New: Hide patron accounts that are for admin use only
by bugzilla-daemon＠bugs.koha-community.org 01 Apr '26

01 Apr '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33965 Bug ID: 33965 Summary: Hide patron accounts that are for admin use only 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 We should have a setting that only superlibrarians can set to hide patron accounts that regular staff should not need to alter. Test accounts, anonymous patron accounts, etc. Superlibrarians would be the only users that could alter accounts marked as such. You should not be able to mark superlibrarian accounts as hidden. Regular staff would be able to see names and card info throughout the system, but they would not be able to view the patron record. They should be shown a screen like "Admin use only." -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 13

[Bug 30795] New: Configure unwanted and mandatory borrower fields based on patron category
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30795 Bug ID: 30795 Summary: Configure unwanted and mandatory borrower fields based on patron category 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: dcook(a)prosentient.com.au QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com It would be nice if there were a way to specify different unwanted and mandatory fields based on patron category (rather than enforcing 1 rule for all different patron categories). At the moment, I see libraries putting in junk data (like '-' or 'N/A') to get around mandatory field requirements where it doesn't make sense for certain patron categories. It makes sense to have a default rule for these fields, and then individual patron categories could be overwritten with more specific rules. -- I suppose the difficulty at the moment is that we don't choose a patron category until we're already on the add patron screen. Maybe we should be making it a multi-step process. That would have its pros and cons of course. Actually, this reminds me of another thought I've had where we could standardize CRUD forms... but I'll open another bug for that... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 16

[Bug 34162] New: Customize required patron registration fields by patron type
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34162 Bug ID: 34162 Summary: Customize required patron registration fields by patron type 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: kkrueger(a)cuyahogalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Some libraries have different required fields by patron type. For example, regular borrowers may be required to have a birth date, but an Institution patron type would not have a birth date to enter in this field. It would be great to be able to customize the borrowermandatoryfield system preferences according to patron type. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 20582] New: Turn Koha into a Mojolicious application (?)
by bugzilla-daemon＠bugs.koha-community.org 31 Mar '26

31 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20582 Bug ID: 20582 Summary: Turn Koha into a Mojolicious application (?) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: julian.maurice(a)biblibre.com Reporter: julian.maurice(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 158

[Bug 29497] New: Add ability to link authorities automatically in the advanced editor
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29497 Bug ID: 29497 Summary: Add ability to link authorities automatically in the advanced editor Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: estherm(a)sodaspringsid.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl It would be nice to add the link authorities automatically button in the advanced editor. Right now catalogers must use the basic editor in order to use this option. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 35953] New: Add delete_any_record cataloguing subpermission
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35953 Bug ID: 35953 Summary: Add delete_any_record cataloguing subpermission Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff interface Assignee: koha-bugs(a)lists.koha-community.org Reporter: wainuiwitikapark(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 27

[Bug 36393] New: Renewal with a specific date does not take the new date due that we pick
by bugzilla-daemon＠bugs.koha-community.org 30 Mar '26

30 Mar '26

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36393 Bug ID: 36393 Summary: Renewal with a specific date does not take the new date due that we pick 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: hammat.wele(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com To reproduce 1- Log in to the staff interface 1-1. Make sure you have a ciculation rule that allows you to renew 1-2. set the AllowRenewalLimitOverride system preference to Allow and SpecifyDueDate to Allow 2. Check out the item to a Borrower 5. Access the borrower's account and renew it until the limit is reached and note the due date. 6. Go to Circulation, click Renew 7. Enter the item barcode and choose a due date further than the due date from step 5 and submit 8. Click on Override limit and renew button ---> Note that the new date due is not the date that we picked in step 7 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24