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

[Bug 21087] New: Patron's password is hashed twice when the object is saved
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21087 Bug ID: 21087 Summary: Patron's password is hashed twice when the object is saved Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: critical Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Depends on: 20287 When a patron is edited (reading the code at least using patron batch modification), the password is lost. Prior to bug 20287 ModMember took the $hash of modification, and '****' was a trick to not update the password (when coming from memberentry). The same trick has been reused for the move of ModMember to Koha::Patron->store, but then the following code will modify the password of the patron: my $password = 'password'; $patron->password($password)->store; $patron->surname('xxx')->store; => User is not longer able to login with 'password' Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20287 [Bug 20287] Move AddMember and ModMember to Koha::Patron -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 28

[Bug 34291] New: Clubs requiring email just don't show if there is no email
by bugzilla-daemon＠bugs.koha-community.org 28 Mar '24

28 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34291 Bug ID: 34291 Summary: Clubs requiring email just don't show if there is no email 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com We were scratching our heads over this one. We were wondering why some clubs were not showing for some patrons, and showing for others. It is because the club is setup to require an email address. Which makes sense. But instead of just hiding the clubs, could they be greyed out or disabled with a red reminder that it requires an email address? This would explain things a lot better. Or, at the very least, if any clubs are hidden, could there at least be a red warning at the top of the clubs that some are hidden because they require an email address? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 18213] New: Add language facets to Elasticsearch
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18213 Bug ID: 18213 Summary: Add language facets to Elasticsearch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org -- You are receiving this mail because: You are watching all bug changes.

1 48

[Bug 23352] New: Set serial issue default values when creating a subscription in serials/subscription-add.pl
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=23352 Bug ID: 23352 Summary: Set serial issue default values when creating a subscription in serials/subscription-add.pl Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Serials Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexbuckley(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com To speed up the process of receiving serial issues libraries should be able to set default serial issue values for the subscription when they create the subscription. Currently, it is possible for librarians to set default values for 952 MARC fields in the bibliographic frameworks but that would set blanket default values for all subscriptions. As different subscriptions are likely to have different 952 MARC field values it would be useful for libraries to set default values which are only applied to the serial issue items created for a specific subscription. The default values they should be able to set when creating the subscription (in serials/subscription-add.pl) are: * Collection code * Subscription full cost Then when a serial issue is received from the two above values the following 952 subfields will be pre-populated: * 952$8 Collection Code - Pulled in from default set in serials/subscription-add.pl * 952$b Current location - Set to the currently logged in library branch * 952$d Date acquired - This will be pre-populated upon page load rather than when you click on the text input field as is the current behaviour * 952$h Serial Enumeration/ chronology - This will be pre-populated from the subscription numbering pattern * 952$v Cost, replacement price - This will be pre-populated from the calculation of the subscription full cost/number of issues This would only leave the librarian to input 952$p (barcode) and 952$a (permanent location), speeding up the cataloguing process of receiving serials. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 82

[Bug 32209] New: Item subfields required even when supplied for each order
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=32209 Bug ID: 32209 Summary: Item subfields required even when supplied for each order Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When using MarcItemFieldsToOrder to populate order information while staging records you can set things up to supply an itemtype, however, if the itemtype field is required, you still must select one on the items tab To recreate: See bug 32166 - use file and settings to add to basket form a staged file Note you must still populate the itemtype on the second tab -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 34827] New: "Item information" tab should not appear when adding to a basket from a staged file if items are created using MarcItemFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 27 Mar '24

27 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=34827 Bug ID: 34827 Summary: "Item information" tab should not appear when adding to a basket from a staged file if items are created using MarcItemFieldsToOrder 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org When adding to a basket from a staged file, we populate item information on the main tab if using MarcItemFieldsToOrder, however, upon submission we can get an error: "Some required item subfields are not set" This is because the second tab 'Item information' uses the standard item editing form, and checks that all required fields are filled. These inputs are ignored when item information is present on the other tab. We should not build this form when using MarcItemFieldsToOrder See bug 20473 -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 26352] New: Add plugin hooks to transform patron barcodes
by bugzilla-daemon＠bugs.koha-community.org 26 Mar '24

26 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=26352 Bug ID: 26352 Summary: Add plugin hooks to transform patron barcodes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Plugin architecture Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Moved from bug 25712 Some of our partners have unusual barcode requirements that have required us to transform scanned barcodes using javascript. This is not the most reliable method. It would make more sense to have Koha transform the barcodes on the backend using a plugin. We should add hooks to transform and generate new item and patron barcodes. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 61

[Bug 16654] New: The output from reports/cat_issues_top.pl is not proper CSV
by bugzilla-daemon＠bugs.koha-community.org 25 Mar '24

25 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16654 Bug ID: 16654 Summary: The output from reports/cat_issues_top.pl is not proper CSV Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org The output from reports/cat_issues_top.pl is *NOT* csv; it is DSV (delimiter separated values) with the option of using commas as delimiters... and the delimiters aren't properly escaped. To illustrate the point 1/ Check out an item whose title contains a comma. 2/ Go to Home [34m~@� Reports [34m~@� Most-circulated items 3/ Select a date range containing today's date 4/ Select the "To a file" radio button, and use comma (,) as the delimiter. 5/ Click Submit Open the file in the spreadsheet program of your choice. Note that the title containing the comma spans two columns, because it was not properly quoted. If the report is going to use CSV as a file extension, it should be exported using Text::CSV_XS, which properly handles CSV export. -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 27641] New: Action buttons on borraccount.pl should allow notes
by bugzilla-daemon＠bugs.koha-community.org 23 Mar '24

23 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=27641 Bug ID: 27641 Summary: Action buttons on borraccount.pl should allow notes Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: george(a)nekls.org QA Contact: testopia(a)bugs.koha-community.org The following action buttons on boraccount.pl should allow staff the ability to add notes: Pay Void Issue refund Issue payout Apply discount And any other action buttons I'm not thinking of. Essentially, if a staff member can modify an accountline from boraccount.pl, there should be a way for them to make a note about that modification. The ability to add notes exists on pay.pl, maninvoice.pl, and mancredit.pl, so it should be available on boraccount.pl. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 8

[Bug 17216] New: Add a new table to store authorized value categories
by bugzilla-daemon＠bugs.koha-community.org 22 Mar '24

22 Mar '24

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17216 Bug ID: 17216 Summary: Add a new table to store authorized value categories Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: ASSIGNED Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jonathan.druart(a)bugs.koha-community.org Reporter: jonathan.druart(a)bugs.koha-community.org QA Contact: testopia(a)bugs.koha-community.org Blocks: 15799 The way we manage authorized values is not consistent: Some are present in the DB, others are not (see bug 15799 comment 4 for more details). Worse, most of the time the FK does not exist (and datatype is not consistent: varchar 32 vs 20, 16,...). To help cleaning up this area, a new table to store authorized value categories would be helpful. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15799 [Bug 15799] Move authorised values related code into Koha::AuthorisedValues - part 2 -- You are receiving this mail because: You are watching all bug changes.

1 148