Bug 7085 - Problems with searching for orders in acquisitions
Summary: Problems with searching for orders in acquisitions
Status: CLOSED FIXED
Alias: None
Product: Koha
Classification: Unclassified
Component: Acquisitions (show other bugs)
Version: 3.6
Hardware: All All
: PATCH-Sent (DO NOT USE) major (vote)
Assignee: Owen Leonard
QA Contact: Ian Walls
URL: /cgi-bin/koha/acqui/histsearch.pl
Keywords:
Depends on:
Blocks: 6807
  Show dependency treegraph
 
Reported: 2011-10-25 12:10 UTC by Katrin Fischer
Modified: 2013-12-05 19:59 UTC (History)
3 users (show)

See Also:
Change sponsored?: ---
Patch complexity: ---
Documentation contact:
Documentation submission:
Text to go in the release notes:
Version(s) released in:


Attachments
screenshot (26.12 KB, image/png)
2011-10-25 12:10 UTC, Katrin Fischer
Details
Proposed fix (1.79 KB, patch)
2011-10-25 14:20 UTC, Owen Leonard
Details | Diff | Splinter Review
[SIGNED-OFF] Fix for Bug 7085 - Problems with searching for orders in acquisitions (1.91 KB, patch)
2011-10-29 13:48 UTC, Katrin Fischer
Details | Diff | Splinter Review
3.4.x version of patch (1.53 KB, patch)
2011-11-27 21:12 UTC, Katrin Fischer
Details | Diff | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Katrin Fischer 2011-10-25 12:10:07 UTC
Created attachment 6048 [details]
screenshot

I see some weird behaviour from the order search in acq. Currently I have 1 record ordered and have problems finding it.

If I search for the title in the order search on top of acquisitions, I can find it. If I use the title option in advanced search - I don't find it. (see screenshot)

I don't get any results using the date options and leaving title and all other fields blank.

The logs show no errors.
Comment 1 Owen Leonard 2011-10-25 14:11:38 UTC
I had similar problems searching, although it was hit and miss. On a fresh database I found I couldn't search for and find the first order I added, but I could search for and find the *second* one.

Checking the SQL generated by GetHistory in Acquisitions.pm I couldn't see any difference between the two queries, but I did notice that the script builds the SQL by checking if inputs are defined:

    if ( defined $title ) {
        $query .= " AND biblio.title LIKE ? ";

I'm not sure when it's appropriate to use "if ( defined $input )" versus "if ( $input )," but changing it to the latter seems to make the query work.
Comment 2 Owen Leonard 2011-10-25 14:20:02 UTC Comment hidden (obsolete)
Comment 3 Katrin Fischer 2011-10-29 13:48:29 UTC
Created attachment 6113 [details] [review]
[SIGNED-OFF] Fix for Bug 7085 - Problems with searching for orders in acquisitions

Changing "if ( defined $input )" to "if ( $input )" in the section
of the script which builds the order search query seems to give
successful searches where they didn't exist before. Searches from
the advanced order search screen work with title, author, vendor,
basket number, date, etc.

Signed-off-by: Katrin Fischer <Katrin.Fischer.83@web.de>
Searches for date ranges, title and author keywords give
me the correct results now.
Comment 4 Ian Walls 2011-11-06 08:49:37 UTC
Replaces 'defined' calls with Perl eval, so any params that are passed defined but 0 or '' do not invoke the addition of the SQL where clauses.  Undefined values will still assess as untrue, so we don't lose anything here, just gain stricter checks.

Marking as Passed QA
Comment 5 Paul Poulain 2011-11-06 09:31:00 UTC
patch pushed, please test
Comment 6 Chris Nighswonger 2011-11-16 14:06:07 UTC
This patch does not apply cleanly to 3.4.x. If it should, please rebase against that branch and attach a corrected patch to this bug.

cnighs@erasmus:~/koha.3.2.test (3.4.x)$ git cherry-pick -x -s 0c0ddf92113b4a5df6
Automatic cherry-pick failed.  After resolving the conflicts,
mark the corrected paths with 'git add <paths>' or 'git rm <paths>'
and commit the result with:

        git commit -c 0c0ddf92113b4a5df6833f75ba5b7ad7527c5f48

cnighs@erasmus:~/koha.3.2.test (3.4.x *+)$ git status
# On branch 3.4.x
# Your branch is ahead of 'origin/3.4.x' by 15 commits.
#
# Unmerged paths:
#   (use "git reset HEAD <file>..." to unstage)
#   (use "git add/rm <file>..." as appropriate to mark resolution)
#
#       both modified:      C4/Acquisition.pm
Comment 7 Katrin Fischer 2011-11-27 21:12:34 UTC
Created attachment 6439 [details] [review]
3.4.x version of patch
Comment 8 Jared Camins-Esakov 2012-05-23 12:13:59 UTC
Included in 3.6 prior to 3.6.5.