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

[Bug 17354] New: Group By/Order By SQL mismatch in issues_stats.pl
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17354 Bug ID: 17354 Summary: Group By/Order By SQL mismatch in issues_stats.pl Change sponsored?: --- Product: Koha Version: 16.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Reports Assignee: gmcharlt(a)gmail.com Reporter: jcoehoorn(a)york.edu QA Contact: testopia(a)bugs.koha-community.org I'm looking in intranet/cgi-bin/reports/issues_stats.pl. I'm not sure of the exact line number, since I may have changed some white space earlier in the file on my system while tracking this down, but near line 350 in that file you'll see this: $colorder = ($colfield =~ /dayname/) ? "weekday($column)" : ($colfield =~ /^month/ ) ? " month($column)" : $colfield; The $colorder value will be used in the ORDER BY clause for the final SQL statement for the report. Contrast that with this code from earlier in the file, which will be used for the GROUP BY and SELECT clauses: $colfield = ($dsp == 1) ? " dayname($column)" : ($dsp == 2) ? "monthname($column)" : There's a clear mismatch here. The earlier snippet should be using "monthname()" instead of "month()", to match the GROUP BY syntax. I found this while playing with Ubunutu 16.04/MySql 5.7. I have turned strict mode off in MySql 5.7, but even with strict mode off the Circulation Report listed under "Statistics Wizards" was broken when I tried to group by month. I suspect grouping by day will be broken as well. The report works as expected for grouping by month after changing to use the monthname() function. -- You are receiving this mail because: You are watching all bug changes.

1 1

[Bug 17133] New: DE Startseite
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17133 Bug ID: 17133 Summary: DE Startseite Change sponsored?: --- Product: Project Infrastructure Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Project website Assignee: wizzyrea(a)gmail.com Reporter: mirko(a)abunchofthings.net Übersetzung der Startseite -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 17004] New: REST API: add route to authenticate patron
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17004 Bug ID: 17004 Summary: REST API: add route to authenticate patron Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Web services Assignee: koha-bugs(a)lists.koha-community.org Reporter: mail(a)jkozlovsky.cz QA Contact: testopia(a)bugs.koha-community.org Add API route to authenticate patron. This would be very useful for 3rd party applications, such as NCIP's LookupUser service or simpleSAMLphp IdP for eduGAIN. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 57

[Bug 22833] New: Don't let users cancel holds connected with ILLs
by bugzilla-daemon＠bugs.koha-community.org 25 Jun '23

25 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=22833 Bug ID: 22833 Summary: Don't let users cancel holds connected with ILLs Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: magnus(a)libriotech.no Target Milestone: --- In the Swedish (Libris) ILL module, when a new ILL request is created, a record and an item (with a specific ILL itemtype) are also created. And a hold is created between the local patron that is waiting for the ILL and the local ILL item. This means that the ILL shows up as a regular hold when the patron logs into the OPAC. That in it self is OK, but the problematic thing is that patrons can cancel the holds connected with the ILL (maybe thinking that they are then also canceling the ILL request). Libraries would like to stop patrons from doing this. A couple of options come to mind: 1. Add a syspref that can take a list of itemtypes that should not be cancel'able by the patron in the OPAC 2. Add a boolean field like itetypes.let_patrons_cancel_holds_in_opac which defaults to 1 for existing itemtypes, but can be set to 0 to achieve the desired effect. 1 is more unobtrusive, 2 is probably cleaner in the long run? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 38

[Bug 29122] New: appends first item barcode to all copies when adding multiple copies
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29122 Bug ID: 29122 Summary: appends first item barcode to all copies when adding multiple copies Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: Linux Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: rlpardhi(a)sipnaengg.ac.in QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When adding multiple copies of item in cataloging, it automatically increments barcode but appends barcode of first copy to all copies along with '|'. Please guide me to resolve this issue. Eg. First copy barcode is: JR004141 Second copy barcode is:JR004142 | JR004141 Third copy barcode is: JR004143 | JR004141 Fourth copy barcode is:JR004144 | JR004141 Fifth copy barcode is: JR004145 | JR004141 Kindly guide how to avoid additional string. Thanks -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 29120] New: improve link_bibs_to_authorities.pl
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29120 Bug ID: 29120 Summary: improve link_bibs_to_authorities.pl Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Command-line Utilities Assignee: koha-bugs(a)lists.koha-community.org Reporter: hagud(a)orex.es QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz /link_bibs_to_authorities.pl links bibliographics with main entry ($a), I wish to discuss with you if this script should also look for match at 4xx for non accepeted entries and replace in case of matchings The idea behind of this featrue is when importing records from external sources for example, add this function that looks for non-accepeted authirity form in your catalogue and if there is a march replace with main entry. Is something we should add the option at koha? -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 18770] New: No update between canceled orders and suggestions status create confusion
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18770 Bug ID: 18770 Summary: No update between canceled orders and suggestions status create confusion Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexandre.breton(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org Hi, me and some of my partners have seen a small bug on our systems. If an order made from a suggestion is canceled, it will stay in the suggestions management with the "ordered" status. We must delete the suggestion or change his status in a second step to correct the situation, if you forgot to do it and have many suggestions on your list, it can be very confusing. Therefore, it will be interesting to have a link between the canceled orders and suggestions management, some kind of an "Auto-changing status for suggestions that the order is canceled". Here is the path to check this bug : 1) Go in the Acquisitions 2) Create a suggestion that isn't in your library. 3) Select your new suggestion and mark it as "accepted". 4) Select a vendor and create a basket (or select an existing one). 5) Clic on "add to basket" and select "from a suggestion". 6) Find your suggestion and clic on "+Order" at the right 7) In the new order page, clic on "Add item", select a fund and save it. 8) Clic on "cancel order" at the right and clic on Ok. 9) Go to suggestions 10) Observe that in Suggestion management you will continue to see your suggestion in the "Ordered" tab... Back in 2012, a similar patch (see bug #5346) was proposed and tested to link them but it seems this was never incorporated into the master. (I must also admit that I'm not sure it will do the trick for me, but it's related.) Thanks for the help, Alexandre from CCSR -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 6

[Bug 29027] New: When an order created from a suggestion is cancelled, suggestion remains as ORDERED
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29027 Bug ID: 29027 Summary: When an order created from a suggestion is cancelled, suggestion remains as ORDERED 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org When an order is created from a suggestion and then cancelled, the suggestion will remain in the status ordered. It would be better if the status could be switched automatically to another custom or pre-defined status, so that those would not remain in "ordered" forever. These are hard to spot for libraries when one has been missed. At the moment you have to create a report on suggestions with a biblionumber and status ordered where the biblionumber no longer exists in aqordres, as it appears to be removed from the order when the record is deleted (also not good). Later on, we could then also think about creating a notice to inform the patron about the cancellation automatically as an enhancement. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 29013] New: Add ability to uncancel an order
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29013 Bug ID: 29013 Summary: Add ability to uncancel an order Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Acquisitions Assignee: koha-bugs(a)lists.koha-community.org Reporter: Malnati(a)ucc.edu QA Contact: testopia(a)bugs.koha-community.org More an enhancement than a bug. I would like the ability to uncancel an order. I was informed that "orders are tied to that cancelled order, so they can't also be tied to a different order and thus budget." -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 8

[Bug 29011] New: Error 500 on item checkout
by bugzilla-daemon＠bugs.koha-community.org 24 Jun '23

24 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=29011 Bug ID: 29011 Summary: Error 500 on item checkout Change sponsored?: --- Product: Koha Version: 21.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Browser compatibility Assignee: oleonard(a)myacpl.org Reporter: jan.michael.mueck(a)uni-hamburg.de QA Contact: testopia(a)bugs.koha-community.org Created attachment 124863 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=124863&action=e… screenshots We want to checkout a item for a user, but have to search it by keywords. In that result list there is a button "ausleihe" (borrow) next to the item we want to checkout. When clicking on that there is an error 500. The item is then borrowed by the user (so everything is correct), but the page still shows error 500. I think its suppused to redirect to the borrowed page of that user.. see attachement. Kind regards -- You are receiving this mail because: You are watching all bug changes.

1 10