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

[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 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 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 6968] New: Show items expired before today in check expiration of serials page
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=6968 Bug #: 6968 Summary: Show items expired before today in check expiration of serials page Classification: Unclassified Change sponsored?: --- Product: Koha Version: master Platform: All OS/Version: All Status: NEW Severity: enhancement Priority: P5 Component: Serials AssignedTo: colin.campbell(a)ptfs-europe.com ReportedBy: pelletiermaxime(a)gmail.com QAContact: koha-bugs(a)lists.koha-community.org Created attachment 5702 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=5702 patch The page Check Expiration the in Serials section show items that are going to expire before the date selected, but doesn't show items that expired before today We needed to see what was already expired, so I added a checkbox to add it as an option. -- Configure bugmail: http://bugs.koha-community.org/bugzilla3/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA Contact for the bug.

1 23

[Bug 14070] New: Notice not saved when mandatory fields are not filled
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14070 Bug ID: 14070 Summary: Notice not saved when mandatory fields are not filled 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: katrin.fischer(a)bsz-bw.de QA Contact: testopia(a)bugs.koha-community.org To test: - Enter a new text for a notice, don't fill the subject line - Save - a note is shown that not all mandatory fields have been filled in - Verify: You are kicked back to the overview page of notices, your changes have not been saved - Start again... -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 24

[Bug 12009] New: Sometimes a koha-common restart won't restart zebra
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12009 Bug ID: 12009 Summary: Sometimes a koha-common restart won't restart zebra Change sponsored?: --- Product: Koha Version: master Hardware: All OS: Linux Status: NEW Severity: minor Priority: P5 - low Component: Packaging Assignee: koha-bugs(a)lists.koha-community.org Reporter: robin(a)catalyst.net.nz QA Contact: testopia(a)bugs.koha-community.org CC: robin(a)catalyst.net.nz I saw this: $ sudo /etc/init.d/koha-common restart [sudo] password for robin: Restarting Koha ILS: daemonexecutablenameStopping Zebra server for nzica SIP server for nzica not running. Stopping Starman for nzica Zebra already running for instance nzica. starting starman for nzica Starting Starman for nzica on port 5002 The "Zebra already running" is a problem, and suggests there may be cases where zebra takes a moment to shut down. It should have a waiting phase where we ensure that the process is really gone before we proceed. -- You are receiving this mail because: You are the assignee for the bug. You are watching all bug changes.

1 1

[Bug 12605] New: TestBuilder - Refactoring Acquisition/close_reopen_basket.t
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12605 Bug ID: 12605 Summary: TestBuilder - Refactoring Acquisition/close_reopen_basket.t Change sponsored?: --- Product: Koha Version: unspecified Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Test Suite Assignee: chris(a)bigballofwax.co.nz Reporter: yohann.dufour(a)biblibre.com QA Contact: gmcharlt(a)gmail.com In order to see what the module TestBuilder can bring to the writing of tests, the tests in Acquisition/close_reopen_basket.t have been refactored with the use of TestBuilder. -- You are receiving this mail because: You are watching all bug changes.

1 8

[Bug 7843] New: RSS for OPAC news
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=7843 Priority: P5 - low Change sponsored?: --- Bug ID: 7843 Assignee: oleonard(a)myacpl.org Summary: RSS for OPAC news QA Contact: koha.sekjal(a)gmail.com Severity: enhancement Classification: Unclassified OS: All Reporter: magnus(a)enger.priv.no Hardware: All Status: NEW Version: master Component: OPAC Product: Koha We have news items in the OPAC - why not create an RSS stream for them? -- You are receiving this mail because: You are watching all bug changes.

1 53

[Bug 12631] New: Inventory: fix "wrong place" and "item not scanned" statuses
by bugzilla-daemon＠bugs.koha-community.org 17 Jun '15

17 Jun '15

http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12631 Bug ID: 12631 Summary: Inventory: fix "wrong place" and "item not scanned" statuses Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: normal Priority: P5 - low Component: Tools Assignee: gmcharlt(a)gmail.com Reporter: matthias.meusburger(a)biblibre.com QA Contact: testopia(a)bugs.koha-community.org What's wrong: ------------- The current behavior in the inventory tool for item statuses is wrong on two points: 1) "item not scanned" status: when calling GetItemsForInventory, datelastseen should be used when "compare barcodes list to result" is checked. Otherwise, when loading multiple barcodes files for the same inventory, many items will be marked as "item not scanned" when loading the last barcode file ("compare barcodes list to result" checked) even though they were scanned. 2) "wrong place" status: when searching for wrongly placed items, we should only check for the location (callnumbers, location and branch). To fix this, A new call to GetItemsForInventory has been made with location filters only. Otherwise, any item with a different itemtype for instance will be marked as wrong place even if the location is correct. Test plan: ---------- Providing a strict and precise test plan is quite hard, as it is strongly dependant of your database, but you can check as follow: "item not scanned" status: 1) Split a barcode file in two. 2) Load the first barcode file without checking "compare barcodes list to result". 3) Load the second barcode file with "compare barcodes list to result" checked. 4) Check in the csv report that you have a lot of scanned items with the "item not scanned" status. Then apply the patch, do the same, and check that the false "item not scanned" statuses are gone. "wrong place" status: 1) Load a barcode file with barcode matching an item that has a correct location, but a different itemtype than what you're looking for. 2) Check in the results that this item will be marked as "change item status" and "wrong place". Then apply the patch, do the same, and check that the only status for this item is "change item status", which is correct. Remarks: -------- I'm expecting concerns about the fact that GetItemsForInventory is now called twice instead of once, but keep in mind that inventory is a quite rare operation. Also, I did not manage to find a more efficient way to fix this wrong behavior, suggestions welcome. -- You are receiving this mail because: You are watching all bug changes.

1 25