January 2019 - Koha-bugs - lists.koha-community.org

[Bug 21633] New: Did finesMode = test ever send email?
by bugzilla-daemon＠bugs.koha-community.org 13 Mar '20

13 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21633 Bug ID: 21633 Summary: Did finesMode = test ever send email? Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Documentation Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org In the 18.05 documentation, finesMode is described thus: Default: Calculate (but only for mailing to the admin) Asks: ___ fines Values: - Calculate (but only for mailing to the admin) [test] - Calculate and charge [production] - Don’t calculate [off] https://koha-community.org/manual/18.05/en/html/systempreferences.html?high… I have interpreted this as "If fines.pl is run and finesMode is set to 'test', fines will be generated in a CSV(ish) file and the file will be emailed to the address in KohaAdminEmailAddress". I have tested this a bit now, and no email with the file seems to be sent. Reading the code, I can not see any signs of an email being sent either. The 3.0 docs has this to say about finesMode: Description: This preference establishes how Koha will handle fines being accrued by patrons. There are three values to choose from: “Off”, Test, and Production. If the “Off” value is put into effect no fines will be calculated. The Test value prompts Koha to email fine notifications. The Production value is selected to allow Koha to start calculating overdue fines. It is important to know that extra programming will be involved to make this preference functional and a cronjob will need to be put into effect. A cronjob is a programming function that issues commands at specific dates and times. https://koha-community.org/files/2010/02/wayne-state-university-koha-3.0-re… So: "The Test value prompts Koha to email fine notifications." But: "It is important to know that extra programming will be involved to make this preference functional." I am starting to believe that the emailing of the file was never really implemented. Maybe we should just remove references to emailing from the docs, the comments in the fines.pl script etc? Or was the intended meaning that fines.pl produces a file that could somehow be sent to the admin, but the "somehow" is left to the reader to implement? Or am I missing something? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 24

[Bug 20334] New: Option for escaping slashes in search queries
by bugzilla-daemon＠bugs.koha-community.org 12 Mar '20

12 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20334 Bug ID: 20334 Summary: Option for escaping slashes in search queries 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: glasklas(a)gmail.com There are a number of reserved characters in the Elasticsearch query syntax (+ - = && || > < ! ( ) { } [ ] ^ " ~ * ? : \ /). Slash (/), which is used for regexps, is quite often used in searches with the intent as it should be interpreted as a literal sting. This causes the search to crash since Elasticsearch treats this as an unclosed regular expression (or a regexp if two slashes are used which can be even more confusing). To address this particular case here is a patch with an option to escape slashes (or require them to be escaped to count as a regular expression delimiter). -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 71

[Bug 18895] New: Lost Items Not Removed From Patron' s Account When Charge is Paid
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18895 Bug ID: 18895 Summary: Lost Items Not Removed From Patron's Account When Charge is Paid Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: cslone(a)camdencountylibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Hi, There is a potentially severe problem when paying the replacement charge for an item if the item is still checked-out to a patron. For example, if your cronjob is set to mark an item lost and you charge patrons for lost items, using anything other than the 'pay' button will not remove the item from the patron's checkouts after the charge has been paid. 'Pay selected,' 'Pay amount,' Write off,' or 'Write off all' will take care of the charge, but the item will remain checked-out and marked as 'Long Overdue / Lost' on the patron's record. Additionally, it is difficult to identify these erroneous items if staff does not catch it them immediately, making it hard to correct lingering problems. To replicate: 1.) Set preference WhenLostChargeReplacementFee to 'Charge' 2.) Edit the record of a checked-out item to the lost status indicated by your DefaultLongOverdueChargeValue. Note: To keep the item checked-out, this must be done by opening and editing the item's record (not directly from the items tab of the bibliographic record). You can also use an item that your longoverdue cronjob marked. 3.) Confirm that the item is still checked-out to the patron and that the replacement fee was charged. 4.) Use pay selected, pay amount, write off, or write off all with the replacement charge and confirm the action as you normally would. 5.) The charge will be removed but the item will still be checked-out to the patron's record. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 14

[Bug 22182] New: Advanced editor - Rancor - Create item record
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22182 Bug ID: 22182 Summary: Advanced editor - Rancor - Create item record Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: jzairo(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Target Milestone: --- Currently you can use the macros feature in the advanced editor -rancor - to create text strings to add fields in a record. It would be a nice enhancement to add the item record fields (952$) via a macro in the editor too. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4

[Bug 18790] New: Add ability to void payments
by bugzilla-daemon＠bugs.koha-community.org 11 Mar '20

11 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18790 Bug ID: 18790 Summary: Add ability to void payments 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: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Depends on: 18786 We've had the ability to 'reverse' a payment for a long time, but it would be much better if we had a true void payment function that replaces the paid amounts into the fee so that it appears as if the payment was never made. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18786 [Bug 18786] Add ability to create custom payment types -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 64

[Bug 19164] New: Allow MARC modification templates to be used in staged MARC imports
by bugzilla-daemon＠bugs.koha-community.org 10 Mar '20

10 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19164 Bug ID: 19164 Summary: Allow MARC modification templates to be used in staged MARC imports Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: koha-bugs(a)lists.koha-community.org Reporter: J.P.Knight(a)lboro.ac.uk QA Contact: testopia(a)bugs.koha-community.org In Bug 18690 Katrin Fischer suggested that it would be useful to have MARC Modification Templates used in stage MARC imports in a similar way to that enhancement's inclusion in bulkmarcimport.pl -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 47

[Bug 16719] New: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16719 Bug ID: 16719 Summary: LDAP: Using empty strings as 'failsafe' attribute mapping defeats database constraints Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: oliver.bock(a)aei.mpg.de QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Created attachment 52316 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52316&action=ed… Patch: proper NULL mapping LDAP attributes with empty values are currently mapped as empty strings, which is described as 'failsafe'. This defeats the existing database constraints (NULL and UNIQUE) without an apparent need. If some kind of empty default is required, it should be set in the mapping config itself, not the code. Please note that this is not just a semantic issue since mapping empty LDAP values as an empty string does indeed cause a constraint violation (read: database error, hence our severity) when such an attribute bears a UNIQUE constraint. This is due to the fact that an empty string is an actual value validated by the constraint (NULL isn't). I don't know the reasoning behind the empty-string mapping but should a NULL-mapping have been the original intention then please note that this behavior is database-dependent. The correct way to map NULL in a database-agnostic way is to use "undef" (see my patch). Thanks -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 20708] New: Withdrawn status should show when placing a request in staff client
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20708 Bug ID: 20708 Summary: Withdrawn status should show when placing a request in staff client Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Hold requests 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 To recreate: 1 - Backup your db (or not, I am not your parent) 2 - Set some items as withdrawn (UPDATE items SET withdrawn = 1) 3 - Try to place some holds 4 - The screen says no items are available, but it is hard to see why 5 - Restore your database, or just live your life :-) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 14

[Bug 15860] New: Alias missing for /plugin on packages
by bugzilla-daemon＠bugs.koha-community.org 09 Mar '20

09 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15860 Bug ID: 15860 Summary: Alias missing for /plugin on packages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: tomascohen(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz Created attachment 48235 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=48235&action=ed… Broken image There is an alias missing on the packages-shipped apache templates. It prevents some things to show on the UI. To test: - Enable the plugins - Install libmarc-lint-perl - Install the MARC checker plugin (https://github.com/bywatersolutions/koha-plugin-marc-checker) - Run the plugin => FAIL: There's a broken image link (see attachment) -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 19489] New: Development for fines and Fees Module - Detailed Description of charges in Patron Account Tab /Fines Tab
by bugzilla-daemon＠bugs.koha-community.org 06 Mar '20

06 Mar '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19489 Bug ID: 19489 Summary: Development for fines and Fees Module - Detailed Description of charges in Patron Account Tab/Fines Tab Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some libraries would like to see the item barcode, due date, and return date ( if any ) for fines in the accounts tables related to fines ( pay.pl and boraccount.pl ). -- You are receiving this mail because: You are watching all bug changes.

1 77