July 2025 - Koha-bugs - lists.koha-community.org

[Bug 33669] New: Adding options to ApplyFrameworkDefaults preference
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33669 Bug ID: 33669 Summary: Adding options to ApplyFrameworkDefaults preference Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Hi ! >From bz29146 and bz30250, a few changes have been made to enhance the way framework default values are applied in a record. But the changes made makes it impossible for someone to add quickly default values to a record they are editing since default values are applied only when a record is created. Before, when we saved a record, every empty field and/or subfield that had default values in the framework would get populated. Of course that was not ideal as someone could want to keep one of those field empty. But right now, if we edit a record, there is no way to populate those field... So I think a great way to keep the inhancement from 29146/30250 but to also have the option to add default values when editing a record (not only when creating one) would be to add two more options to ApplyFrameworkDefaults preference : - When repeating a field - When repeating a subfield This way, if my framework has a default value in field 336, for exemple, and I edit a record that has an empty 336 field, I could only use the "repeat this field" button to have a 336 field populated with my default values. The empty 336 would simply disappear when saving my record. And it would be the same for the subfield option, but having the two separated allows a bit more flexibility if a library wants to have default values when adding a complete field but not if they only repeat a subfield and vice versa. Thank you ! -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 33583] New: Put back the biblionumber coloumn in batch records import table
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=33583 Bug ID: 33583 Summary: Put back the biblionumber coloumn in batch records import table Change sponsored?: --- Product: Koha Version: 22.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Hi, In 21.05, the record column in the batch records import table displayed the biblionumber of the imported record. Now, this column displays 2 buttons : edit and view. It would be nice to keep those two buttons but also have the option to have the biblionumber displayed in that table. A couple of libraries would use this table to export a list of records to edit (add an image, edit the items, etc.) after the import. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 32617] New: Koha thinks a rule is currently being edited if All patron All type rule has a hard due date
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32617 Bug ID: 32617 Summary: Koha thinks a rule is currently being edited if All patron All type rule has a hard due date Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, I didn't know how to summerize this bug more than that as it is a VERY specific situation haha ! Context : When we are currently editing a rule and we don't save it and try to edit another rule, a message pops up and says : Are you sure you want to edit another rule? to alert us that we didn't save the rule we are editing. Problem : So if we have a rule with Patron category set to All and Item Type also set to All and this rule has a Hard Due Date, we always have the Are you sure you want to edit another rule? message that pops up when we want to edit a rule. The message pops up only if the All Patron and All type rule has a Hard Due date, I don't replicate if I set a Hard Due Date on another rule... I don't know if I explain that well so here's a test plan : 1. Create a rule with Patron Category and item type set to All with any other settings but don't set a Hard Due date 2. Create a rule with a specific Patron Category and a specific Item Type with any other settings 3. When both rules are saved, try to edit one of them. You will be able to do so as usual 4. Edit the All Patron All Item type rule and add a Hard Due Date. Save the rule. 5. Try to edit again any of the rule, you then have the Are you sure you want to edit another rule? as if we were currently editing a rule when in fact all rules are saved. 6. Delete the Hard Due Date on the All patron All Item Type rule and save the rule. 7. Try to edit a rule again and the message doesn't pop up. I tried that on 21.05 and then on ByWater's 22.05 demo and replicate the problem every time. Thank you -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 31804] New: Filtering not working when searching for a basket number on the receive orders page
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31804 Bug ID: 31804 Summary: Filtering not working when searching for a basket number on the receive orders page Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org Not a duplicate of bz31322 as I don't recreate the behaviour described. I am able to search with the box above the table and the box in every other colomn in the table, but not in the basket one. I don't have any kind of error or any kind of odd behaviour, the filtering just doesn't work when I am searching for a basket number. It seems to search only on the date. In previous version, searching for a basket number was filtering correctly the table. To recreate : Go to the receive orders page for any vendor Try searching for one of the basket number in the box above the table - Every line of the table disappear as if there was no basket with this number Try searching the same number in the Basket search box - same result Try searching for the date of the basket - appropriate lines are filtered Thank you -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 29907] New: The 'type' column in the public lists table is redundant
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29907 Bug ID: 29907 Summary: The 'type' column in the public lists table is redundant Change sponsored?: --- Product: Koha Version: 20.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Lists Assignee: koha-bugs(a)lists.koha-community.org Reporter: noemie.labine(a)collecto.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 129627 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=129627&action=e… 'Type' column In the OPAC when we go to the lists page to see all the lists, there is a column for the 'type' of list. For the public tab, this information is redundant as you are already in the public tab. The 'type' can't be anything else than public... With the private lists tab, the type can change if you have a shared list, but for the public lists there are no other type. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 36755] New: Increase length of 'code' column in borrower_attribute_types
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=36755 Bug ID: 36755 Summary: Increase length of 'code' column in borrower_attribute_types Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: pedro.amorim(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Plugins may want to make use of patron attribute types thus prepending some data to the code of a patron attribute type they may need could be useful e.g. kitchensink_somefield. Currently, the 'code' is limited to VARCHAR(10) so this not possible. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 28

[Bug 35931] New: More preselected items in the renew column on details page and on checkout page
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=35931 Bug ID: 35931 Summary: More preselected items in the renew column on details page and on checkout page Change sponsored?: --- Product: Koha Version: 22.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: reetta.pihlaja(a)siilinjarvi.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When viewing and renewing patron's checkouts on details page or on checkout page, only the items with past due dates are preselected as a default in the renew column. Would it be possible to preselect also the items with current due dates here, as a default? This would help a lot at the customer service. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 19

[Bug 38067] New: Default cash register follow up to 36844
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=38067 Bug ID: 38067 Summary: Default cash register follow up to 36844 Change sponsored?: --- Product: Koha Version: 24.05 Hardware: All OS: All Status: NEW Severity: trivial Priority: P5 - low Component: Point of Sale Assignee: koha-bugs(a)lists.koha-community.org Reporter: holly(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: martin.renvoize(a)ptfs-europe.com Nick commented on 36844, comment 9: "I found that when switching from a branch with a default register to one without, the default register for the last branch was remaining selected (though disabled)"h When switching from library A to library B the cash register should switch to register B or none. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 40420] New: Add Patron API call should respect mandatory borrower fields
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=40420 Bug ID: 40420 Summary: Add Patron API call should respect mandatory borrower fields Change sponsored?: --- Product: Koha Version: Main Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: REST API Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: tomascohen(a)gmail.com When creating a patron via the API, the call will fail when missing the values required by the API itself (surname, library, category) and if it's missing a patron attribute that's marked as mandatory for the staff interface (see bug 40220). However, the API call succeeds and makes a patron when missing values defined as mandatory in either BorrowerMandatoryField or PatronSelfRegistrationBorrowerMandatoryField. To recreate: 1: set BorrowerMandatoryField to include surname, library, category and anything else. I used phonepro (secondary phone) 2: use Postman or similar to add a patron, sending only surname, library, and category 3: confirm your patron is created without the required secondary phone (or whatever you used) 4: set PatronSelfRegistrationBorrowerMandatoryField to match BorrowerMandatoryField 5: repeat steps 2 and 3 Following discussion on other bugs, I think we have an open question whether this should follow BorrowerMandatoryField or PatronSelfRegistrationBorrowerMandatoryField or a new third option of APIBorrowerMandatoryField. But it should follow something. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 17983] New: Add minutes loan to DiscreteCalendar
by bugzilla-daemon＠bugs.koha-community.org 28 Aug '25

28 Aug '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17983 Bug ID: 17983 Summary: Add minutes loan to DiscreteCalendar Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Holidays Assignee: koha-bugs(a)lists.koha-community.org Reporter: mehdi.hamidi(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org Hello everyone, This is an additional feature to our new Discrete Calendar. Theses patches add the possibility to choose the loan unit as minutes in circulations rules. Test plan: - Apply patch of Bugzilla 17015 - Apply this patch. - Run test t/db_dependent/minutes_loan.t - Create new item type for the new rule. - Create circulation rule and fill the fields, make sure the unit is set to : minutes, choose the item type of the one created above.- - Checkout an item that follow the circulation rule and set due date in the past. - Run fines.pl. - Check if the correct amount was calculated. - Note: make sure to factor in the fine grace period if set and the system preference FinesIncludeGracePeriod. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 49