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

[Bug 21707] New: Wrong CSRF token - adding a new patron with auto generated card number turned on
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21707 Bug ID: 21707 Summary: Wrong CSRF token - adding a new patron with auto generated card number turned on Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: cfhong2000(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Trying to add a new patron by entering Surname and click Save. Card Number leave blank since it is using auto-generated. The following error was thrown. Software error: Wrong CSRF token at /usr/share/koha/intranet/cgi-bin/members/memberentry.pl line 307. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 5

[Bug 21859] New: Fields to choose on Notice editor often contains non-applicable tables and fields
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21859 Bug ID: 21859 Summary: Fields to choose on Notice editor often contains non-applicable tables and fields Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Staff Client Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com The fields to insert section of the notices and slips editor (Home › Tools › Notices & slips › Modify notice) bases the fields to add on 'letter.module'. Unfortunately, this means that there are often tables shown that are not actually available on the notice in question. The most extreme example are DUEDGST and PREDUEDGST, which can only use <<branches.*>>, <<borrowers.*>>, <<items.content>> and <<count>>, but shows <<biblio.*>>, <<biblioitems.*>>, <<items.*>>, <<opac_news.*>> and <<issues.*>>, all of which are un-available. This is part of the Notice documentation rfc (https://wiki.koha-community.org/wiki/Notice_documentation_rfc) See also Bug 21858. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21884] New: Writeoff "amount" changed from positive values to negative values.
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21884 Bug ID: 21884 Summary: Writeoff "amount" changed from positive values to negative values. Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Fines and fees Assignee: koha-bugs(a)lists.koha-community.org Reporter: alexanderchen530(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Created attachment 82653 --> https://bugs.koha-community.org/bugzilla3/attachment.cgi?id=82653&action=ed… Example of pos/neg writeoff values. Hi, This is not a recent issue, I discovered it either after 17.05 or 17.11 update. Before the update, writeoff amounts were displayed in "red positive numbers", but after the update, writeoff amounts became "green negative numbers" just like payments. This is not an issue if it's just humans reading it, but it becomes an issue when doing accounting and stats, when I was totaling fines during a certain time range, positive/negative values cancel each other and provide inaccurate total fine amounts. I used ABS() as a workaround, but I hope it can be fixed globally to keep it uniform. Please see attached pics. Also ticket "#49563: Difference in positive and negative values in writeoff charges" has some discussion as well. I also spoke to Kyle regarding this issue at KohaCon18. Thanks. Alex C -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6

[Bug 21922] New: Allow to decide if price is entered tax inlcuded or excluded on receive
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21922 Bug ID: 21922 Summary: Allow to decide if price is entered tax inlcuded or excluded on receive Change sponsored?: --- Product: Koha Version: 17.11 Hardware: All OS: All Status: NEW Severity: enhancement 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 At the moment the decision if prices entered on receive are inclusive or exclusive taxes is made by settings on vendor level. It would be nice if the list price setting could be overridden on receive to avoid having to do those calculations manually. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 2

[Bug 21923] New: Sort problem in some letters of Patron list
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21923 Bug ID: 21923 Summary: Sort problem in some letters of Patron list Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Patrons Assignee: koha-bugs(a)lists.koha-community.org Reporter: kohadevinim(a)devinim.com.tr QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com While applying patch Bug 21778, we've seen that some Turkish characters on Surname yield incorrect sort order. Ç,İ,Ö,U should come after C,I,O,U. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 9

[Bug 21954] New: Koha update having a strange effect on checkout rules
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21954 Bug ID: 21954 Summary: Koha update having a strange effect on checkout rules Change sponsored?: --- Product: Koha Version: 18.11 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: librarian(a)darwin.cam.ac.uk QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com I have chased a few false trails and was stuck with a checkout error on all items. When checking out books, we kept receiving "No circulation rule is defined for this user and itemtype combination." On checking, all circulation rules were defined as necessary. Rules were in place for both Books and DVDs, for all user categories. We managed to get it to work by placing another rule for 'All' categories, 'All' itemtypes as an overhead. This should never be used following the hierarchy of the rules, but it seems to allow all of the other rules to now be followed (they have become valid). This has a workaround - the all/all rule, but it would be good to know what is going on. It is also good to note that this was working before on 18.05! -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21988] New: Add SMSSendDriverFromNumber system preference for specifying a source number for SMS messages
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21988 Bug ID: 21988 Summary: Add SMSSendDriverFromNumber system preference for specifying a source number for SMS messages Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Notices Assignee: koha-bugs(a)lists.koha-community.org Reporter: andrew.isherwood(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org Some SMS gateways (specifically, in my case, http://123-txt.com) require a "source" number to be specified which all SMS messages appear to be sent from. This bug proposes adding a SMSSendDriverFromNumber syspref, similar to the new EmailSMSSendDriverFromAddress (Bug 20356), to allow a source number to be specified. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 21

[Bug 21512] New: CalculateFinesOnReturn doesn't work without the syspref finesMode
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21512 Bug ID: 21512 Summary: CalculateFinesOnReturn doesn't work without the syspref finesMode 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: olli-antti.kivilahti(a)helsinki.fi QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com Fines are not created for checking in an Item, if the syspref 'CalculateFinesOnReturn' is enabled without the syspref finesMode being in the 'production' -mode (Calculate and charge). CalculateFinesOnReturn must work without the fines.pl -feature. The problem is with the subroutine C4::Circulation::_CalculateAndUpdateFine() Initially it looks like it must be invoked from the fines.pl as well. But that subroutine is only used within the C4::Circulation module for AddRenew and AddReturn. Hence the _CalculateAndUpdateFine() has nothing to do with fines.pl|finesMode. This patch replaces the finesMode-check with CalculateFinesOnReturn-check. I am not sure why there needs to be a specific syspref for the fines.pl, or why CalculateFinesOnReturn is needed, as the fine amounts can be tweaked using the circulation rules matrix and the fines.pl-cronjob can either be ran, or not, with an endless possibility of parameters that shouldn't be in the sysprefs. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 9

[Bug 21510] New: Authority search always jumps back to the first search tab no matter what was searched for
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21510 Bug ID: 21510 Summary: Authority search always jumps back to the first search tab no matter what was searched for Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor 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 Go to: - Authorities module - Select not the first tab for searching - Search - Notice with reloading the page, search jumps to the first tab -- You are receiving this mail because: You are watching all bug changes.

1 2

[Bug 21496] New: install.pl: DBD::mysql::st execute failed: Index column size too large. The maximum column size is 767 bytes. at /usr/share/perl5/DBIx/RunSQL.pm line 273.
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21496 Bug ID: 21496 Summary: install.pl: DBD::mysql::st execute failed: Index column size too large. The maximum column size is 767 bytes. at /usr/share/perl5/DBIx/RunSQL.pm line 273. Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Database Assignee: koha-bugs(a)lists.koha-community.org Reporter: migraciones(a)grupoisv.com QA Contact: testopia(a)bugs.koha-community.org Hi, I found the next error when I am installing Koha install.pl: DBD::mysql::st execute failed: Index column size too large. The maximum column size is 767 bytes. at /usr/share/perl5/DBIx/RunSQL.pm line 273. The opertive system is Debian 8 Database is 10.0.32-MariaDB-0+deb8u1 Koha version is Koha 18.05 I need help please Thank you -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12