March 2018 - Koha-bugs - lists.koha-community.org

[Bug 19490] New: Add a 'holds' column to the Batch Item Modification Tool
by bugzilla-daemon＠bugs.koha-community.org 18 Nov '19

18 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19490 Bug ID: 19490 Summary: Add a 'holds' column to the Batch Item Modification Tool Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: jesse(a)bywatersolutions.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org Some librarians would like to know the holds activity for items when using the batch modification tool. We should display a holds count column to the batch item modification tool that will show the number of holds on an item / holds for entire record -- You are receiving this mail because: You are watching all bug changes.

1 27

[Bug 18723] New: Dot not recognized as decimal separator
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '19

15 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18723 Bug ID: 18723 Summary: Dot not recognized as decimal separator Change sponsored?: --- Product: Koha Version: 16.11 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 Since we work on 16.11, we can't use dot when we receive orders but only comma (for example : a price 11.25€ will be changed in 1125,00€ after receiving the order). It seems linked to syspref "Currencyformat" because the behaviour is different when we change it from FR to US format (a price 15,43€ will be changed in 15,430.00€). When we worked on 3.20 until this april, we could use both dot and comma when receiving books. This is quite disturbing for staff users because a dot is required when adding an order to a basket, whereas a comma must be used when receiving the book but there is no warning like it exist in the basket. I don't know if it's a similar problem to the "Bug 18186 - Amounts with decimal comma instead of decimal dot breaking payments" about the circulation module. We also work with plack, but even without it, we still have this bug. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 74

[Bug 17359] New: Patron import results use wrong encoding
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '19

15 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=17359 Bug ID: 17359 Summary: Patron import results use wrong encoding Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: mirko(a)abunchofthings.net QA Contact: testopia(a)bugs.koha-community.org When using the patron import tool, the summary at the end uses wrong character encoding. Upload a csv with a few fields and include some ü ö ä. To trigger an error, not providing a surname in the file should work, or a non numeric cardnumber. You will see broken Umlauts on the results page. (The imported data is ok, only the summary is not) -- You are receiving this mail because: You are watching all bug changes.

1 46

[Bug 19507] New: Add a sample CSV profile for exporting lost items
by bugzilla-daemon＠bugs.koha-community.org 15 Nov '19

15 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19507 Bug ID: 19507 Summary: Add a sample CSV profile for exporting lost items Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Installation and upgrade (web-based installer) Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Bug 9573 adds the possibility to export lost items using CSV profiles. It would be nice to have the example added to the web installer files: Title=biblio.title |Author=biblio.author |Lost status=items.itemlost |Lost on=items.itemlost_on |Barcode=items.barcode |Call number=items.itemcallnumber |Date last seen=items.datelastseen |Price=items.price |Rep. price=items.replacementprice |Library=items.homebranch |item type=items.itype |Current location=items.holdingbranch |Location=items.location |Not for loan status=items.notforloan |Notes=items.itemnotes -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 19740] New: Self checks calculating wrong due dates / configuration changes go unnoticed
by bugzilla-daemon＠bugs.koha-community.org 13 Nov '19

13 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19740 Bug ID: 19740 Summary: Self checks calculating wrong due dates / configuration changes go unnoticed Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: SIP2 Assignee: koha-bugs(a)lists.koha-community.org Reporter: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org CC: colin.campbell(a)ptfs-europe.com When using a self check via SIP2 a calendar change will take no effect resulting in due dates being calculated differently for self checks than on the circulation desk. The calculation will remain false until the SIP server is restarted. This also seems to apply to system preference changes, which happen less often. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 3

[Bug 19770] New: Add cardnumber to holds awaiting pickup screen and add classes to borrower info
by bugzilla-daemon＠bugs.koha-community.org 12 Nov '19

12 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=19770 Bug ID: 19770 Summary: Add cardnumber to holds awaiting pickup screen and add classes to borrower info 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: nick(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Some libraries use a combination of borrowers surname and cardnumber on hold slips, this seems to be a fairly common occurence. To facilitate this it would be nice to have the cardnumber available on the waiting holds report. Additionally it would be nice to have classes add to the borrower information so that they can be accessed via javascript for constructing the special code used. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 21

[Bug 20407] New: Hide some fields from unauthoriezd users
by bugzilla-daemon＠bugs.koha-community.org 08 Nov '19

08 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20407 Bug ID: 20407 Summary: Hide some fields from unauthoriezd users Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: REST api Assignee: koha-bugs(a)lists.koha-community.org Reporter: alex.arnaud(a)biblibre.com The main goal here is to be able to make some fields/properties/columns "non public" to unauthorized people ( permission => catalogue ) by setting a "x-public" key to false in Swagger definitions files. Patch is coming... -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 12

[Bug 15732] New: Remove accountno column from accountlines
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=15732 Bug ID: 15732 Summary: Remove accountno column from accountlines Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: kyle(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org How that we have accountlines_id, accountno is superfluous. We should remove it. -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 18587] New: LDAP: update_local is entirely untested!
by bugzilla-daemon＠bugs.koha-community.org 07 Nov '19

07 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=18587 Bug ID: 18587 Summary: LDAP: update_local is entirely untested! Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P3 Component: Authentication Assignee: gmcharlt(a)gmail.com Reporter: martin.renvoize(a)ptfs-europe.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org, gmcharlt(a)gmail.com, hblancoca(a)gmail.com, katrin.fischer(a)bsz-bw.de, martin.renvoize(a)ptfs-europe.com, mtj(a)kohaaloha.com, oliver.bock(a)aei.mpg.de, tomascohen(a)gmail.com Depends on: 14625 The update_local routine inside C4/Auth_with_ldap.pm is entirely untested :(. Reading the code, there are assumptions within it that don't hold true either. For instance, it is assumed that the routine always returns 'cardnumber', when in fact, it can return 'undef' or an integer specifying the number of rows updated by the procedure.. which should only ever be '1'. Referenced Bugs: https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14625 [Bug 14625] LDAP: mapped ExtendedPatronAttributes cause error when updated on authentication -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 20040] New: FailedLoginAttempts syspref will lock out users so that they cannot log in unless the syspref is cleared
by bugzilla-daemon＠bugs.koha-community.org 06 Nov '19

06 Nov '19

https://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=20040 Bug ID: 20040 Summary: FailedLoginAttempts syspref will lock out users so that they cannot log in unless the syspref is cleared Change sponsored?: --- Product: Koha Version: 17.05 Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Authentication Assignee: koha-bugs(a)lists.koha-community.org Reporter: barton(a)bywatersolutions.com QA Contact: testopia(a)bugs.koha-community.org CC: dpavlin(a)rot13.org I think that the FailedLoginAttempts system preference is only meant to be set ifNorwegianPatronDBEnable is set to 'Enable'; my testing is all done with ifNorwegianPatronDBEnable set to 'Disable'. What's happening: Setting FailedLoginAttempts, then logging in with incorrect credentials will lock the account. The login screen says that the account is locked, and no further attempts to log in will work. It is entirely unclear how to unlock the account -- resetting the password does not work, and the lock is not set via borrower debarments, so it can't be disabled there. The only way I was able to re-enable logins for a locked patron was to blank out FailedLoginAttempts. If this is only meant to be used in conjunction with ifNorwegianPatronDBEnable, it shouldn't be settable unless that is enabled. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 6