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

[Bug 21561] New: Check out restriction to category / branch
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21561 Bug ID: 21561 Summary: Check out restriction to category / branch Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: Circulation Assignee: koha-bugs(a)lists.koha-community.org Reporter: joseanjos(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com, kyle.m.hall(a)gmail.com As discussed here: http://koha.1045719.n5.nabble.com/Check-out-restriction-to-category-branch-… its not possible to restrict holds between one library to a group of libraries. With independentbraches it will restrict everything, including Patrons modification. IndependentBranchesPatronModifications should prevent that but doesn't do it. The pretended is this: 1 Main Library (City hall Library CHL) 20 School Libraries (on the same server) Assuming that if a Patron from a School wants to be patron of CHL it will be duplicated Shouldn't be possible checkout from CHL to any school Patron Shouldn't be possible checkout from school to any CHL Patron Should be possible to transfer from CHL to any school Patron and vice-versa School Staff category should be able to modify Patrons because: - Every student is created with is student Nº - On next year he can change from school - Librarian from school should be able to change Library from Student This last point is very important! Otherwise only super librarians can change it. That would be impossible to manage because hundreds of students change every year. The Librarian of each school MUST do that job. Something like Library transfer limits but Library Holds limits would be nice -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 21609] New: Store pre-rendered html in search engine (zebra or elastic).
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21609 Bug ID: 21609 Summary: Store pre-rendered html in search engine (zebra or elastic). Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org XSLT rendering is slow, I started to think about whether it would be possible to store pre-rendered HTML in zebra or elastic, so that we only have to run the marcxml to html xslt transformations at indexing time rather than per, search. It's a time vs. space optimization, and I don't know if the html generated by xslt ever gets cached; if it does, we might not see any benefit. Anyway, putting it out for discussion. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 21642] New: create patron card template in koha generate error not assign template id
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21642 Bug ID: 21642 Summary: create patron card template in koha generate error not assign template id Change sponsored?: --- Product: Koha Version: 18.05 Hardware: All OS: Linux Status: NEW Severity: enhancement Priority: P5 - low Component: Tools Assignee: koha-bugs(a)lists.koha-community.org Reporter: it.officer(a)ppsu.ac.in QA Contact: testopia(a)bugs.koha-community.org create patron card template in koha generate error not assign template id -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 2

[Bug 21677] New: MARC detail view may show field header info erroneously
by bugzilla-daemon＠bugs.koha-community.org 08 Oct '23

08 Oct '23

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=21677 Bug ID: 21677 Summary: MARC detail view may show field header info erroneously 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: pasi.kallinen(a)joensuu.fi QA Contact: testopia(a)bugs.koha-community.org If the fields in the marcxml are not in order, and LabelMARCView is set to compact, the MARC detail view can show the field headers multiple times. To reproduce: 1) Turn on LabelMARCView 2) Turn on EnableAdvancedCatalogingEditor (Rancor allows entering fields in any order, unlike the old editor) 3) Catalogue a new record with the following fields in this order: 655 _ _ ‡afoo 100 _ _ ‡abar 655 _ _ ‡abaz 650 _ _ ‡aqwerty 655 _ _ ‡aqux 655 _ _ ‡aquux 4) Go to that record's MARC detail view. In the 6xx tab, you will see three separate entries for 655 fields: 655 $a foo 655 $a baz 655 $a qux $a quux How it should look: 655 $a foo $a baz $a qux $a quux -- You are receiving this mail because: You are watching all bug changes.

1 6

[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