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

[Bug 13487] New: DataTables pagination needs some fixes
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '15

19 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13487 Bug ID: 13487 Summary: DataTables pagination needs some fixes Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Templates Assignee: oleonard(a)myacpl.org Reporter: jonathan.druart(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org On acqui/basketgroup.pl and catalogue/itemsearch.pl, the sPaginationType DT parameter is not explicitly defined. This broken the pagination display. Moreover, since the DT upgrade (bug 12986), the full_numbers pagination adds a span (containing '...'). It is not managed by the css file and is put at the end of the page numbers ( "1 2 3 4 5 20 NEXT LAST ...", we expect "1 2 3 4 5 ... 20 NEXT LAST"). -- You are receiving this mail because: You are watching all bug changes.

1 24

[Bug 12954] New: Questionable logic regarding session handling in C4::Auth::checkauth()
by bugzilla-daemon＠bugs.koha-community.org 19 Jun '15

19 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12954 Bug ID: 12954 Summary: Questionable logic regarding session handling in C4::Auth::checkauth() Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: major Priority: P5 - low Component: Architecture, internals, and plumbing Assignee: gmcharlt(a)gmail.com Reporter: abl(a)biblos.pk.edu.pl QA Contact: testopia(a)bugs.koha-community.org In case of the unsuccessfull log-in attempt (non-existing user ID, bad password, or both), session params are currently (since Bug 10952 got pushed) being set like that in checkauth(): - lasttime & ip params are set, - number, id, cardnumber, firstname etc. are not set, - sessiontype is NOT set to 'anon' So the user session is essentially left in semi-authorised, semi-anonymous state. If then such an user goes directly to any page which does require authorisation/authentification, checkout() would treat this user as authentificated one, and would return prematurely without redirection to the login screen. This also typically (?) leads to get_template_and_user() being bypassed: it does return to the script from which it was called from (but with empty $borrowernumber return value). In case of the (e.g.) opac/opac-user.pl script, observable effect of this bug is an DBI error: opac-user.pl: DBD::mysql::st execute failed: You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near '' at line 1 at /home/koha/devkohaclone/C4/Letters.pm line 200 (because C4::Letters::getalert() doesn't like to be called with empty $borrowernumber). To replicate: 1/ try to log in with some nonexisting user id or wrong password in OPAC 2/ go directly to the opac/opac-user.pl page (e.g., enter it in the browser address bar, or just click on the "Log in" link); clicking on "Log in" button, when "Login" field is empty would also probably trigger this error 3/ observe DBI error displayed on the screen 4/ you are now in the "deadloop" of sorts (opac/opac-user.pl refuses to display the login screen, no matter how many times you try to reload it); to break the deadloop, one needs to: - remove session cookie from the browser (or cause the session to expire in some other way - closing browser window would be probably enough for that) - remove offending session on the server (from mysql sessions table, ..) - log in with proper credentials using some other page (like opac/opac-main.pl right-side panel), which does not involve opac/opac-user.pl being called without "userid" CGI parameter. Another way to replicate: 1/ try to log in with some nonexisting user id or wrong password in OPAC 2/ go to the staff interface 3/ observe that login screen displayed is different (not the "normal" one, but one with some additional buttons for loging-out etc. + "You do not have permision to access this page" message; see Bug 12951 attachment 31689 for reference). -- You are receiving this mail because: You are watching all bug changes.

1 36

[Bug 14417] New: Facet labels sorted incorrectly (OPAC) and inconsistently (OPAC vs Staff)
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14417 Bug ID: 14417 Summary: Facet labels sorted incorrectly (OPAC) and inconsistently (OPAC vs Staff) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: minor Priority: P5 - low Component: Searching Assignee: gmcharlt(a)gmail.com Reporter: nick(a)quecheelibrary.org QA Contact: testopia(a)bugs.koha-community.org While working on Bug 14371 I noticed the line in opac-search.pl: @$facets = sort {$a->{expand} cmp $b->{expand}} @$facets; This seems to be intended to sort facets so that labels display in order in search results, however, it doesn't work. 'expand' contains the facet index code (su-geo, itype, au, se ...) instead of the label value (Places, Item Types, Author, Series) so sorting doesn't work out ('Places' sorts after 'Series') The actual labels are assigned by and IF statement in opac-facets.inc and are translatable so I think any sorting would have to be done post page creation (javascript?) No sorting of any kind is applied in catalog/search.pl, so facet results between staff/opac don't match up. -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 14413] New: map internalnotes to MarcFieldsToOrder
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14413 Bug ID: 14413 Summary: map internalnotes to MarcFieldsToOrder 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org Right now MarcFieldsToOrder doesn't take the note field, we should add the ability to map a marc field to the aqorders.order_internalnote -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 14414] New: add field for processing fee for invoices
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14414 Bug ID: 14414 Summary: add field for processing fee for invoices 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: nengard(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org It would be great if there was a way to track the default processing fee per vendor and enter a processing fee and a processing fee fund on the invoice management screen. So I see 3 new db fields here: aqbooksellers.processingfee aqinvoices.processingfee aqinvoices.processingfee_fund -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 9290] New: Restricting patron category for online purchase suggestion
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=9290 Bug ID: 9290 Summary: Restricting patron category for online purchase suggestion Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: new feature Priority: P5 - low Component: OPAC Assignee: oleonard(a)myacpl.org Reporter: vinod_librarian(a)rediffmail.com At present by default all the category of patrons can either place purchase suggestions or not via opac. The requirement is the purchase suggestions should be restricted by category of users which can be provided by option at the time of creating patron category (i.e. can place purchase request via OPAC or not) -- You are receiving this mail because: You are watching all bug changes.

1 5

[Bug 11905] New: when editing item, cursor is positioning in search box and not to item
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=11905 Bug ID: 11905 Summary: when editing item, cursor is positioning in search box and not to item Change sponsored?: --- Product: Koha Version: 3.12 Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Cataloging Assignee: gmcharlt(a)gmail.com Reporter: marjorie.barry-vila(a)ccsr.qc.ca QA Contact: testopia(a)bugs.koha-community.org CC: m.de.rooy(a)rijksmuseum.nl Created attachment 25914 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=25914&action=edit search box edit item Hi, In 3.12 (or 3.10), a catalog search box has been added to edit item page. When i click on edit, cursor is positioning in search box and not to the item i want to edit. If i have 100 items, i have to scroll to the end of the page. Anyone can test it? Regards, Marjorie -- You are receiving this mail because: You are watching all bug changes.

1 23

[Bug 3309] Deleting authorized values when data exists
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=3309 Marjorie Barry-Vila <marjorie.barry-vila(a)ccsr.qc.ca> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |marjorie.barry-vila(a)ccsr.qc | |.ca -- You are receiving this mail because: You are watching all bug changes.

1 0

[Bug 13521] New: Auth.pm code issues
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=13521 Bug ID: 13521 Summary: Auth.pm code issues Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low 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, mtompset(a)hotmail.com Depends on: 13499 Blocks: 12548, 12954, 13503 Whilst working on bug #13499 a number of minor code issues were highlighted by perltidy. I'll collect patches in here to fix various issues -- You are receiving this mail because: You are watching all bug changes.

1 16

[Bug 14400] New: Automated backup to cloud storage - Dropbox (tm)
by bugzilla-daemon＠bugs.koha-community.org 18 Jun '15

18 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14400 Bug ID: 14400 Summary: Automated backup to cloud storage - Dropbox (tm) Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: System Administration Assignee: koha-bugs(a)lists.koha-community.org Reporter: indradg(a)gmail.com QA Contact: testopia(a)bugs.koha-community.org CC: gmcharlt(a)gmail.com Current cron job handle automated backup of Koha database and config schema. This patch is designed to extend the function of automated backup on Dropbox based cloud storage. -- You are receiving this mail because: You are watching all bug changes. You are the assignee for the bug.

1 3