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

[Bug 17150] New: Cancelling holds over process needs improvement
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17150 Bug ID: 17150 Summary: Cancelling holds over process needs improvement Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Hold requests 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 Created attachment 54584 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=54584&action=ed… Cancel Hold buttons I'm not seeing a bug with all of this spelled out exactly, so if I repeat something already posted, I'm sorry. It may be that some of this needs to be broken into different bugs, or is already addressed in another bug. I am linking together what I know to be part of the problem, but not the whole picture. Cancelling a hold that is over is a tedious process at best. I'll try to explain what we are seeing. So, when we go to the Holds over tab in the Holds awaiting pickup, we find the item. Issue #1 (holds01.png): Even though the buttons are different, they don't act different, they are not even necessarily accurate about the item, and they have lost functionality between 3.18 to 3.22. Issue #2: Even though a transfer might be triggered, you have to check the item in to get the slip. Waste of time. It should come up with this choice when the transfer is triggered while cancelling (holds04.png). Issue #3: Even though the item might have another hold request, it isn't revealed when you cancel the hold. So, you have to check EVERYTHING in that you cancelled to see if there is a hold, or a pending transfer. Again, this should happen when cancelling the hold. Issue #4: As mentioned in issue #1, the buttons are not very accurate about what happens next with the item. Sometimes there is a hold request at the current location (holds05.png). So, you have to check ALL of these items in to find out if they have holds. Again, this should happen when cancelling the hold. Issue #5: Even though there is a hold request for an item you are cancelling, cancelling the hold applies a transfer. So, when you check the item in after cancelling, you see a transfer to the item's home location AND the hold request (holds06.png). This is CONFUSING and crazy. Especially if it is to the same location. We end up having to cancel the hold, check the item in, cancel the transfer, check the item in again, and then trigger the hold. Why not just skip cancelling the transfer and trigger the hold? Because the transfer will still be in the system! Crazy! Issue #6: When you cancel a hold, you get bounced back to the Holds waiting tab, so you have to click back over to the Holds over tab for the next item. I think there is another bug on this one, but I can't find it at the moment. So, why don't we just use the Cancel All button (by the way, shouldn't it read "Cancel all")? Because not all the items are still in our hands. Some items end up walking out without being checked out. Issue #7: It would be great if there were a button to mark the item missing, or maybe someone calls and finds out the person has the item, so a button to check the item out to that patron would be great. Issue #8: I've noticed another little quirk. If you compare holds04.png with holds06.png, you'll see that the transfer popups are different. holds04.png has no buttons. Just links. I know that one transfer is related to the hold, which doesn't make sense because when we cancel it, it doesn't affect the hold. Issue #9: You may also notice on holds06.png, the address fits on the full line in the transfer popup, but not in the holds popup. The popup boxes are the same size, and the bullets offset in the same place, so something is off on the formatting. Issue #10: Cancelling a hold takes 2 to 3 times longer in 3.22 than it did in 3.18. This is surprising since the popups were taken away! So, ideally, if these are legitimate issues, and are addressed, this is what we would expect to see: 1: Just show a Cancel button for all items with the words "Cancel hold". What happens when you click the button should be self explanatory. Perhaps if Koha didn't have to determine the next status of the item just to create a button, the refresh of the page would improve. Hmmmmm.... 2: When you cancel a hold, if the item needs to go home, it will show the transfer popup to let you print the slip. 3: When you cancel a hold, if the item has a hold, it doesn't trigger a transfer, and only shows the hold popup, whether it is a local hold or going somewhere else. 4: Whether it has a popup or not, when done with the popup it should put you back on the same tab you were last on. 5: Buttons should be on the transfer popup. 6: Formatting should be consistent between the hold and transfer popups (I know, this is sooooo trivial). 7: We should have more options for holds that are over, than just Cancel, since there are other things that can be happening, like missing or already with the patron. A "Mark missing" button and a "Checkout to this patron" button would be nice. Sorry if this sounds like a rant. I know that how we do things isn't the way everyone does things, but this has bugged me for a LONG time, and I think these are some great improvements, even if they need to be tweaked a bit to accommodate other workflows. I will add the screens and see alsos in a moment. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 20

[Bug 17145] New: Cannot upload .mrc file for staging Marc records
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17145 Bug ID: 17145 Summary: Cannot upload .mrc file for staging Marc records Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: MARC Bibliographic record staging/import Assignee: gmcharlt(a)gmail.com Reporter: vermeir_bram(a)hotmail.com QA Contact: testopia(a)bugs.koha-community.org Today I upgraded the koha installation from 3.20.05 to 16.05.02 All seems to work just fine, except for the uploading of a mrc file for staging. Errormessage: Upload failed -- unable to store file on server I checked the Koha logs and found this script not found or unable to stat: /usr/share/koha/intranet/cgi-bin/tools/upload-file-progress.pl I checked the location and indeed the upload-file-progress.pl file is missing. I downloaded the file and uploaded it to the correct folder Next errormessage: AH01215: (2)No such file or directory: exec of '/usr/share/koha/intranet/cgi-bin/tools/upload-file-progress.pl The uploads directory has the correct rights and is located in /var/lib/koha/biblio/uploads can someone please help me out? -- You are receiving this mail because: You are watching all bug changes.

1 3

[Bug 17113] New: Unable to search multi-domain Active Directory forest due LDAP required base
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17113 Bug ID: 17113 Summary: Unable to search multi-domain Active Directory forest due LDAP required base Change sponsored?: --- Product: Koha Version: 3.22 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: helpdesk(a)neci.edu QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org Auth_with_ldap currently prevents the use of an empty base due to the presence of my $base = $ldap->{base} or die ldapserver_error('base'); An AD Global Catalog search will automatically query all domains in a forest if a blank base is specified, but otherwise limits the search to the domain matching the base. Not being able to specify an empty base makes things difficult if the forest contains disjoint domains that cannot be combined into a single search base. (Uncertain how this interacts with the work on bug 8993, but being able to use the forest wide Global Catalog searches removes a lot of the contortions needed to direct requests to the correct host responsible for a domain.) -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16979] New: Search for barcode containing parentheses fails
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16979 Bug ID: 16979 Summary: Search for barcode containing parentheses fails Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Searching for a call number containing parentheses, similar to: 1234567890 (text) or 1234(5678)90 fails to return any results, either in the staff interface or OPAC. For the first barcode, leaving off "(text)" will return the expected result, but removing the parentheses from the latter still does not. The issue (and I suspect the solution) seems similar to 15468 and 12405 in that, if I modify the URL to include %22 around the barcode, I get the expected result. To reproduce : 1) Set up an item with a barcode with the form: 1234567890 (text) 2) In the staff interface, perform a barcode search for the exact barcode 3) No results are returned 4) Modify the search URL to include %22 around barcode e.g.: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234567890+(text)&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234567890+(text)%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 5) Press enter 6) The expected result is returned 7) Setup an item with a barcode with the form: 1234(5678)90 8) In the staff interface, perform a barcode search for the exact barcode 9) No results are returned 10) Modify the result URL to include %22 around barcode e.g. .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=1234(5678)90&op=and&idx=kw&op=and&idx=kw&sort_by=relevance becomes: .../cgi-bin/koha/catalogue/search.pl?idx=bc&q=%221234(5678)90%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance 11) Press enter 12) The expected result is returned -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 16930] New: Search returns no results if "and" appears before a colon
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16930 Bug ID: 16930 Summary: Search returns no results if "and" appears before a colon Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: jyorio(a)esilibrary.com QA Contact: testopia(a)bugs.koha-community.org Search returns no results for an exact title search. Steps to duplicate: 1. Create a record with a title like: This is a test title and for testing only : An Example Value 2. Do a title search for the exact title: This is a test title and for testing only : An Example Value 3. No results will be found 4. Change the title to: This is a test title : An Example Value and for testing only 5. Do a title search for the exact title: This is a test title : An Example Value and for testing only 6. The search returns a result. -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 16137] New: Simplify patron deletion error handling
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16137 Bug ID: 16137 Summary: Simplify patron deletion error handling Change sponsored?: --- Product: Koha Version: master Hardware: All URL: /cgi-bin/koha/members/deletemem.pl OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: oleonard(a)myacpl.org QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com When deleting a patron, there are some cases handled by deletemem.pl which stop the process and redirect to moremember.pl. Other cases stop the process and display an error in the deletemem.tt template. Is there any reason not to redirect all deletion errors to moremember.pl and eliminate the need for deletemem.tt? -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 16827] New: Remove "by" before primary access point.
by bugzilla-daemon＠bugs.koha-community.org 11 Jan '20

11 Jan '20

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=16827 Bug ID: 16827 Summary: Remove "by" before primary access point. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: verolencinas(a)yahoo.com.ar QA Contact: testopia(a)bugs.koha-community.org Created attachment 52933 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=52933&action=ed… Screenshot of OPAC showing a conference record. After showing the title with the statement of responsability the OPAC shows the primary access point preceded by the word "by". In case of defendants, corporate bodies and conferences it is odd to have this word preceding an authorized access point. This word should be deleted in the OPAC and if there are libraries who want to maintain the "by" practice, it should be possible to add a system preference to do so. -- You are receiving this mail because: You are watching all bug changes.

1 1

[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