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.
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.
Created attachment 6050 [details] [review] Proposed fix 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.
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.
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
patch pushed, please test
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
Created attachment 6439 [details] [review] 3.4.x version of patch
Included in 3.6 prior to 3.6.5.