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

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

04 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 04 Dec '25

04 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 04 Dec '25

04 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 04 Dec '25

04 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 03 Dec '25

03 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

[Bug 31422] New: Library limitations might cause data loss
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=31422 Bug ID: 31422 Summary: Library limitations might cause data loss Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, michaela.sieber(a)kit.edu The library limitations are used to limit down the selection in pull downs in several spots. If you are editing data from library B while logged in at library A, doing so might result in data loss as the value stored in the modified object might be missing from the drop downs your user sees. Example 1: Item values Itemtype: BK Books - limited to Centerville AV LOC: FIC Fiction - limited to Centerville Your user: logged in for Centerville * Edit an item and make sure it uses the itemtype Books and location Fiction. * Switch library to any but Centerville. * Edit item: Both item type and location drow downs will be empty. * Saving now will empty out itemtype (if not set mandatory) and location resulting in data loss. Example 2: Patron data Patron category: Patron PT - limited to Centerville Your user: logged in for Centerville * Find a patron with the limited patron category * Edit patron: Verify the patron category shows in pull down * Switch library to any but Centerville * Edit patron: the category pull down will show the first entry of the pull down visible for this library. Saving now, you will change the patron category unknowingly resulting in data loss. Additional bug: If you search for "all patrons", you will have an error in the console no patrons will display: Uncaught TypeError: categories_map[data] is undefined. Filed as bug 31421. I think we need to make sure that the pull downs show what the library can use, but also what the current setting of the object is in order to prevent data loss. IIRC the funds pull down on the receive page uses a mechanism for this. Otherwise library limitations are very dangerous to use and can only be recommended if we can make sure that objects from other libraries cannot be edited at all where library limitations have been applied. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 42

[Bug 20269] New: Allow selecting default collate rule
by bugzilla-daemon＠bugs.koha-community.org 03 Dec '25

03 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20269 Bug ID: 20269 Summary: Allow selecting default collate rule Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org For some languages, the default collate rule set in kohastructure.sql, utf8_unicode_ci, doesn't work correctly. For example, Finnish alphabet expects the alphabet to sort abc...xyzåäö, but the unicode_ci rule doesn't handle the åäö right. Instead, we need to use the swedish_ci rule. It would be nice to be able to define the default collate rule during install. Problem can be seen for example when you go catalogue a new record and have frameworks starting with 'ä' or 'ö', those will sort incorrectly. On the database, you can test this with: insert into biblio_framework (frameworkcode, frameworktext) values ('TEST', 'Äänikirja'); -- Note where the 'Äänikirja' is located select * from biblio_framework order by frameworktext collate utf8_unicode_ci; -- And then the correct order, with 'Äänikirja' last: select * from biblio_framework order by frameworktext collate utf8_swedish_ci; -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 30298] New: Ability to print labels from Serial Collection
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '25

02 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=30298 Bug ID: 30298 Summary: Ability to print labels from Serial Collection Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 131758 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=131758&action=e… add-button-option It would be great to have a print label button from the serial collection information in the serials module. cgi-bin/koha/serials/serials-collection.pl?subscriptionid=1 After a user saves or updates the latest issue they are taken to the serial collection page where they have buttons for editing generating the next serial and deleting selected issues. It would be helpful to have a button to print the labels for the items a user just created from this screen. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 28911] New: Bcrypt settings are required for pseudonymization but are not set on upgrade
by bugzilla-daemon＠bugs.koha-community.org 02 Dec '25

02 Dec '25

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=28911 Bug ID: 28911 Summary: Bcrypt settings are required for pseudonymization but are not set on upgrade 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Bug 24151 added a way to pseudonymize patron transactions. It added a new config to koha-conf <bcrypt_settings> This is added for new installs, but not for upgraded sites, and there are no instructions on the syspref or elsewhere for adding To recreate: 1 - Spin up a 20.05 (checkout 20.05.x and reset_all in kohadevbox) 2 - Upgrade to master (checkout master, updatedatabase) 3 - Enable pseudonymization 4 - Attempt a checkout 5 - boom you can manually add the settings by running the command below: htpasswd -bnBC 10 "" password | tr -d ':\n' | sed 's/$2y/$2a/' And pasting the results into <bcrypt_settings> in the config -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 16