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

[Bug 16824] New: No branchcode argument passed to Koha::Calendar->new at /usr/share/koha/lib/C4/Circulation.pm line 3423.
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16824 Bug ID: 16824 Summary: No branchcode argument passed to Koha::Calendar->new at /usr/share/koha/lib/C4/Circulation.pm line 3423. Change sponsored?: --- Product: Koha Version: 3.22 Hardware: PC OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: himt.library(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 1

[Bug 16804] New: Searching can be broken by search terms containing semicolons in XSLT
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16804 Bug ID: 16804 Summary: Searching can be broken by search terms containing semicolons in XSLT Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org As of CGI version 2.64 ( which was a long time again ) Perl's CGI module began supporting the use of the semicolon (;) as a key value pair separator in addition to the ampersand (&) which Koha currently uses. This causes an issue where is search string is truncated at the semicolon. Not only can this cause issues with incorrect searches/results, it can cause malformed CCL which causes Koha to return no search results! Test Plan: 1) Create a record with a 490$a series statement where there is a semicolon at the end 2) Enable OPAC Suppression 3) Search for the record and click the "Series:" link 4) You will get no results This is because the search: se,phr:"Report to the Mississippi Legislature ;" is converted to se,phr:"Report to the Mississippi Legislature When the opac suppression is tacked on, we get malformed CCL: (se,phr="Report to the Mississippi Legislature ) not Suppress=1 This is not an issue if we simply search for se,phr:"Report to the Mississippi Legislature ;" because the search form properly encodes the semicolon. The solution appears to be to make sure all URL elements are properly url encoded and converts all ";" to "%3B". I do notice that in koha-tmpl/intranet-tmpl/prog/en/xslt/MARC21slimUtils-MODS31.xsl we have a template url-encode that may prove useful. -- You are receiving this mail because: You are watching all bug changes.

1 29

[Bug 16783] New: MARC 008 Material Type change back to CR
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16783 Bug ID: 16783 Summary: MARC 008 Material Type change back to CR Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic data support Assignee: gmcharlt(a)gmail.com Reporter: imingchan(a)yahoo.com.au QA Contact: testopia(a)bugs.koha-community.org MARC 008 (Material Type) doesn't stay what has been selected. Creating a lot of cataloguing records for journal citations, so changed Leader > Position 7 to "B - Serial component part". We then changed MARC 008 > Material Type to "BKS - Books" and successfully saved the catalogue record (no problem here). However, when we reopened MARC 008, the Material Type keep changing back to "CR - Continuing Resource" instead of remain as "BKS - Books"! -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16771] New: Use TT Price plugin to display monetary amounts formatted
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16771 Bug ID: 16771 Summary: Use TT Price plugin to display monetary amounts formatted Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org Using this bug for noting places where we should use the new Price plugin to show monetary amounts formatted according to the chosen system preference value. koha-tmpl/intranet-tmpl/prog/en/modules/reserve/request.tt ...[% borrowerfirstname %] [% borrowersurname %]</a>: <strong>Patron has outstanding fines: [% amount_outstanding | format('%.2f') %]</strong></li> -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16679] New: Translatability problems in system preferences
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16679 Bug ID: 16679 Summary: Translatability problems in system preferences Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: I18N/L10N Assignee: koha-bugs(a)lists.koha-community.org Reporter: veron(a)veron.ch QA Contact: testopia(a)bugs.koha-community.org CC: frederic(a)tamil.fr Koha's system preferences are constructed and displayed in a very elegant way in English, but not all languages have the same syntax, and we get a lot of translation issues due to sentence splitting. In some cases, translators can work around such problems, but we will always have odd translations. Odd translations do not look very professional at all, and they can lead to misunderstandings and misconfigurations. Additionally, it is very frustrating and discouraging for translators. IMO, the best way to get rid of such translation problems would be to use whole sentences, followed by the preference's value. Example (taken from Bug 16669): Instead of... [Don't use/Use] CAS for login authentication. ...the following would be much better in terms of translatability: Use CAS for login authentication: [Yes / No] -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 16639] New: Split item data from description in Fines tab into separate columns
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16639 Bug ID: 16639 Summary: Split item data from description in Fines tab into separate columns Change sponsored?: --- Product: Koha Version: 3.20 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: theod(a)lib.auth.gr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As an alternative approach to https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16461 , it would be far better if separate "Barcode", "Due Date" and "Branch" columns were created in the Fines->Account table and Fines->Pay Fines So, my proposal for the for the Fines->Account table would be something like: Date | Description of charges | Barcode | Due Date | Branch | Note | Amount | Outstanding | Print And accordingly for the Fines->Pay Fines table: Fines & charges | Description | Barcode | Due Date | Branch | Payment note | Account type | Notify id | Level | Amount | Amount outstanding (The new tables /seem/ to have many columns to fit into the screen, but the "Description" column doesn't have to be as long as it used to, so the result will fit) Be warned that this approach assumes also that separate columns should be created in the accountlines db table to hold (at least) the branchcode (and/or the item barcode). -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 7

[Bug 16606] New: Checkout settings dropdown should have a preference to stay open all the time
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16606 Bug ID: 16606 Summary: Checkout settings dropdown should have a preference to stay open all the time Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation 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 Not everyone is concerned with the additional space taken up with the new Checkout settings. It would be helpful if these options could be set to always show. For now I will use a jQuery to force it open, but a preference would be preferable. No pun intended. Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 16604] New: Break down patron modification requests for approval/give reasons for denials/allow corrections
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16604 Bug ID: 16604 Summary: Break down patron modification requests for approval/give reasons for denials/allow corrections Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client 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 It would be helpful to have the ability to select what changes to approve, and give reasons for denial that would show up somewhere on the patron account or in an e-mail to the patron. It would also be helpful if the changes were editable if mistakes are found (misspellings, no caps, hyphenations, etc.) I would imagine check boxes next to each line of change, and a text box next to each line for "Reason". The reason "could" be saved for both approvals and denials. However, if a reason is given, it would be appropriate to send the reason to the patron. Perhaps the information is incorrect. The patron should be notified. The changes should also be editable. I would imagine an edit button next to the change, which would simply change the text from a label to a text box, with a save and cancel button. I don't think it would be good to have it always editable without a button or link, in case someone accidently changes something. Whether or not staff provide reasons, the approval or denial should be shown to the patron either in their account, or in an e-mail, if they have one, and show any modifications (i.e. Approved or denied, what was on the account before, what the patron requested, what it was actually changed to, reasons if they exist.) Christopher -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 16523] New: Ability to choose NONE for the libraries limitation in authorised values
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16523 Bug ID: 16523 Summary: Ability to choose NONE for the libraries limitation in authorised values 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: cbrannon(a)cdalibrary.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Currently you have to choose at least one library on an authorized value. However, I would like to be able to have a location of CART, with a user friendly description, but not give ANY libraries the ability to choose it manually. I only want the check in process to use it. There should be a NONE option in the list. Christopher -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 16483] New: Ampersand breaks search for analytics
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16483 Bug ID: 16483 Summary: Ampersand breaks search for analytics Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: magnus(a)libriotech.no QA Contact: testopia(a)bugs.koha-community.org A customer has reported the following problem: A journal is catalogued with separate records for each issue. The journal has an ampersand in the title, let's call it "This & that". Each issue has 245$a like "This & that 2011-1", "This & that 2011-2" and so on. For each issue, there are analytical records. Now, when you are on the detail view of one of the issues in the staff client (<intranet>/cgi-bin/koha/catalogue/detail.pl?biblionumber=12657) and click on "Show analytics", you get results from all issues of the journal, not just the one you wanted. The URL you are taken to looks like this: <intranet>/cgi-bin/koha/catalogue/search.pl?q=Host-item:This & that 2011-3. Above the search results it says: 14 result(s) found for 'Host-item:This ' in MyLibrary Catalog. Note that the title has been cut before the ampersand. It is possible to tweak the search URL (remove the ampersand) and get the expected results. Changing the URL to this: <intranet>/cgi-bin/koha/catalogue/search.pl?q=Host-item:This that 2011-3. gives this: 8 result(s) found for 'Host-item:This that 2011-3.' in MyLibrary Catalog. The same thing happens in the OPAC. I guess a workaround will be to enable UseControlNumber and follow the descriptions here: https://wiki.koha-community.org/wiki/Analytics -- You are receiving this mail because: You are watching all bug changes.

1 3