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

[Bug 31113] New: Permission change to so user can use marc modification template only when adding or editing single record
by bugzilla-daemon＠bugs.koha-community.org 13 Dec '25

13 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31113 Bug ID: 31113 Summary: Permission change to so user can use marc modification template only when adding or editing single record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: aspencatteam(a)clicweb.org QA Contact: testopia(a)bugs.koha-community.org Would like to see a permission to allow the application of marc modification template to single record, without having the permission to do batch record modification. This would allow admin to create marc modification template that a novice cataloger could use to supply certain fields they probably would not know to change. (Like in leader, 008, 007). We would not want them to be able to do batch record modification - just use template on single record. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 30343] New: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt
by bugzilla-daemon＠bugs.koha-community.org 12 Dec '25

12 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30343 Bug ID: 30343 Summary: Any failed delivery method in overduerules.pl produces a printed notice in attachment.txt Change sponsored?: --- Product: Koha Version: 21.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org Previously we had only used the e-mail delivery method in overduerules.pl. This worked great. When a patron didn't have an e-mail address, a printed notice was added to the attachment.txt file for printed notices. Now we have phone and sms added as delivery methods. However, if ANY of these fail (no SMS number or no primary phone, or in the case of Twilio, if the same notice is sent via e-mail or sms, the phone status shows as deleted to prevent duplication) a printed notice is added to the attachment.txt file for printed notices. There should be option to determine if a printed notice is generated if ANY of the other methods fail, or if ALL of the methods fail. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 4

[Bug 20338] New: Preference noissuescharge should not be considered 5 when it is actually 0
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '25

09 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20338 Bug ID: 20338 Summary: Preference noissuescharge should not be considered 5 when it is actually 0 Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: josef.moravec(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When the noissuescharge is set to 0, then limit 5 is used, see FIXME comment in circ/circulation.pl after bug 19933 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 25219] New: Include note in fines-related system preferences which can be disabled by leaving them blank
by bugzilla-daemon＠bugs.koha-community.org 09 Dec '25

09 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25219 Bug ID: 25219 Summary: Include note in fines-related system preferences which can be disabled by leaving them blank Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The syspref OPACFineNoRenewals includes the note "(leave blank to disable)." The sysprefs maxoutstanding, noissuescharge, NoIssuesChargeGuarantees, and MaxFine can all be disabled by leaving them blank, as well. It'd be helpful to include that same "(leave blank to disable)" message to make it clear. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 29140] New: Suppress some warnings in codemirror js editor
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29140 Bug ID: 29140 Summary: Suppress some warnings in codemirror js editor 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When editing user JS preferences there are warns for: 'let' is available in ES6 I think we could suppress these and allow that usage -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 20508] New: Validation for *MandatoryField and *UnwantedField sysprefs
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20508 Bug ID: 20508 Summary: Validation for *MandatoryField and *UnwantedField sysprefs 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: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com When any the system preferences BorrowerMandatoryField BorrowerUnwantedField PatronSelfModificationBorrowerUnwantedField PatronSelfRegistrationBorrowerMandatoryField PatronSelfRegistrationBorrowerUnwantedField are being populated, we should check that a) The entered fields are columns in the borrowers table b) Mandatory / Unwanted fields that refer to the same form (BorrowerMandatoryField/BorrowerUnwantedField and PatronSelfRegistrationBorrowerMandatoryField/PatronSelfRegistrationBorrowerUnwantedField) do not contain the same fields. c) If autoMemberNum is set, don't allow cardnumber in *MandatoryField See also: * Bug 17433 * Bug 19642 * Bug 19225 -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 22848] New: Ability to merge suggestions
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22848 Bug ID: 22848 Summary: Ability to merge suggestions 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Target Milestone: --- It can easily happen that multiple suggestions for the same record are made. It would be nice if there was an option to merge them and keep both patrons who made the suggestion linked to it. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 5

[Bug 25911] New: Chrome tries to save patron passwords
by bugzilla-daemon＠bugs.koha-community.org 05 Dec '25

05 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=25911 Bug ID: 25911 Summary: Chrome tries to save patron passwords Change sponsored?: --- Product: Koha Version: 19.11 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 If you are like me, you might have your browser try to save passwords for sites. I like having the browser in my office save some of my passwords. Logging into Koha is one of them. However, the problem with this is, every time I save a form that has a password associated with it, it wants to remember this password. This includes patron records. This is an annoyance. Now, my testing has been only with Chrome on this particular issue, and my workaround addresses this to some degree. So, if there is a more all-encompassing issue to address or solution, feel free to chime in. I've been able to work around this annoyance by adding the following to jQuery: $('#pat_memberentrygen #password,#pat_memberentrygen #password2').attr('readonly','').attr('onfocus','$(this).removeAttr("readonly");'); This will make the password fields readonly, which Chrome will ignore. If you need to edit the field, when you click on it, it will take the readonly attribute away, and it can be edited. Left as is, when you save, it will, of course, try to save the password. But it will only do so if the password is edited. If you leave it untouched, it will not bug you. I can take this one step further, I add this line to add the readonly attributes before saving. Then it won't bug me to save the password at all: $('#pat_memberentrygen #validate').attr('onmouseover', '$("#pat_memberentrygen #password,#pat_memberentrygen #password2").attr("readonly","");'); NOTE: Our Save button has the ID of "validate" because I have some validation code added to the form. But you get the idea here. When you hover over the save button, it adds the readonly attribute, and is ignored by the browser. I don't know if this helps anyone, or gives anyone an idea how to keep patron forms from being a nuisance to staff that save credentials, but I thought I would throw it out here. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 30633] New: Move OPACHoldingsDefaultSortField to table settings configuration
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30633 Bug ID: 30633 Summary: Move OPACHoldingsDefaultSortField to table settings configuration 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Depends on: 29648 Now that the sorting of a table can be defined in administration > table settings, we should move OPACHoldingsDefaultSortField there and remove the pref. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29648 [Bug 29648] Make KohaTable tables 'default length' and 'default sort' configurable -- You are receiving this mail because: You are watching all bug changes.

1 61

[Bug 20271] New: Merge deleted/old tables with their "alive" cousins
by bugzilla-daemon＠bugs.koha-community.org 04 Dec '25

04 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20271 Bug ID: 20271 Summary: Merge deleted/old tables with their "alive" cousins Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P1 - high Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: boutrosboutrosboutros(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org In Koha's DB, instead of having a "soft" deletion of entries by flagging the deleted one as so, the rows in the db is actually deleted, but only after a new row in a different table is inserted. Koha's DB is relational, so there is a cascade of links between each object: a biblio is referred by many items, and each item is referred by issues, holds, messages. E.g.: when a row in the item table is moved from "items" to "deleted_items", then all the references from holds, transfers and so on will be broken. The suggested more orthodox approach to this would be to add a "deleted_at" column, which is normally null unless the row is deleted, then it set to the timestamp of when it was deletion. This means that the row is still there and will still be referred by other tables, but it just won't be shown in the relevant lists. This would improve the maintenance of Koha in many ways (e.g.: the auto_increment id on those tables caused lots of issues when you add an item and delete it immediately after. the next new item will have the same itemnumber as the previously deleted one, clashing with it in many ways). This bug is about merging the all these tables: deletedborrowers => borrowers deletedbiblio => biblio deletedbiblioitems => biblioitems deletedbiblio_metadata => biblio_metadata deleteditems => items old_issues => issues old_reserves => reserves -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 383