June 2018 - 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 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 19716] New: Add option to send header line for CSV output
by bugzilla-daemon＠bugs.koha-community.org 22 Jun '23

22 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19716 Bug ID: 19716 Summary: Add option to send header line for CSV output Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Reports Assignee: koha-bugs(a)lists.koha-community.org Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Currently, if outputting a CSV file using runreport.pl, you need to look at the report used to know what each column means. It would be nice if we could include column headers. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 12

[Bug 20373] New: Add floating toolbar on new acqui/basketgroups.pl page
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20373 Bug ID: 20373 Summary: Add floating toolbar on new acqui/basketgroups.pl page 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: severine.queune(a)bulac.fr QA Contact: testopia(a)bugs.koha-community.org On the new page acqui/basketgroups.pl created by ticket 11708, it would be useful to have a floting toolbar. Some librairies (like the BULAC) may have a lot of basket groups and this new useful page is not that ergonomic when scrolling down for the title and sorting lign is not persistent. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 20711] New: Previous fields are not cleared when selecting an authority in notice editor
by bugzilla-daemon＠bugs.koha-community.org 21 Jun '23

21 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20711 Bug ID: 20711 Summary: Previous fields are not cleared when selecting an authority in notice editor Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Cataloging Assignee: koha-bugs(a)lists.koha-community.org Reporter: david.bourgault(a)inlibro.com QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl When choosing an authority for a zone in the bibliographic notice editor, existing fields are not cleared. So if I have a information in the subfields $a $v $9 and I import a authority notice with subfields $a $9 $x, the previous $v value is not cleared. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3

[Bug 20478] New: Advance notices: send separate digest messages per branch
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '23

19 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20478 Bug ID: 20478 Summary: Advance notices: send separate digest messages per branch Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andreas.jonsson(a)kreablo.se QA Contact: testopia(a)bugs.koha-community.org Current behavior for advance_notices.pl is to send one digest message for each borrower. The sender for the message is then set to the branch where the borrower is registered, which can be different from the branch or branches on the issues in question. Desired behavior is that the sender address on the notice message is that of the branch of the issues in question. Thus, the solution is to generate digest messages per branch. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 49

[Bug 20640] New: Allow migrating a request between backends
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '23

19 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20640 Bug ID: 20640 Summary: Allow migrating a request between backends Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: ILL Assignee: koha-bugs(a)lists.koha-community.org Reporter: martin.renvoize(a)ptfs-europe.com Currently, once an ILL request has started on a path in one backend it cannot be migrated to another. We should allow the status graph to be modified with 'MoveFrom' and 'MoveTo' methods allowing a request to be migrated from one backend to another when both backend support it (and when the request hasn't progressed sufficiently in one backend to prevent cancellation) -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 81

[Bug 19111] New: Do not mess with kohafield in authority_subfield_structure
by bugzilla-daemon＠bugs.koha-community.org 11 Jun '23

11 Jun '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19111 Bug ID: 19111 Summary: Do not mess with kohafield in authority_subfield_structure Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: koha-bugs(a)lists.koha-community.org Reporter: m.de.rooy(a)rijksmuseum.nl QA Contact: testopia(a)bugs.koha-community.org Please see also bug 10306 and dependencies. In Koha we are using kohafield in auth_subfield_structure only for the link between authid and 001, as well as authtypecode and 942a. We do not have any further "kohafield functionality" as on the biblio side for additional fields like title, author, etc. (There is no authority counterpart for transform marc to koha, etc.) Sub GetAuthMARCFromKohaField is only called a few times (once in AuthoritiesMarc.pm and twice in authorities.pl). In e.g. SearchAuthorities, GuessAuthid, AddAuthority, etc. 001 is hardcoded. This actually means that you should really NEVER change the "kohafield" mapping in the Subfield structure of Admin/Authority types for 001 and 942a. I would propose here to disable the kohafield for editing on the subfield structure form (just as on bug 19096), and at least add some comments to GetAuthMARCFromKohaField. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 4