[Bug 14861] New: Date comparison does not work in advanced search
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Bug ID: 14861 Summary: Date comparison does not work in advanced search Change sponsored?: --- Product: Koha Version: master Hardware: All OS: All Status: NEW Severity: enhancement Priority: P5 - low Component: Searching Assignee: gmcharlt@gmail.com Reporter: barton@bywatersolutions.com QA Contact: testopia@bugs.koha-community.org According to the documentation here: http://manual.koha-community.org/3.18/en/searchguide.html#searchguide-syntax A CCL search may be constructed as follows: (paraphrasing) Index(,search type)=Search String The documentation uses the following as a date search: yr,st-numeric=>2000 Following the same pattern, I used the following to search for a normalize date: acqdate,st-date-normalized=>2015-08-01 This returned Results of search for 'acqdate,st-date-normalized: >2015-08-01' No results found! To re-create: Add an item with the acquisition date set to 2015-08-01 (and let the fast indexer pick it up). Put the string acqdate,st-date-normalized=>2015-08-01 In the 'search the catalog' search box and run the serch. You will see Results of search for 'acqdate,st-date-normalized: >2015-08-01' No results found! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|Date comparison does not |Accession date comparison |work in advanced search |does not work in advanced | |search -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |dcook@prosentient.com.au --- Comment #1 from David Cook <dcook@prosentient.com.au> --- Hey Barton, I can explain the cause (and solution). Check out "ccl.properties": Date-of-publication 1=31 r=r yr Date-of-publication pubdate Date-of-publication Date-of-acquisition 1=32 acqdate Date-of-acquisition st-numeric 4=109 r=o st-name-normalized 4=101 If you look at the Zebra docs, you'll see that r=o and r=r are special attributes for doing range searches (http://www.indexdata.com/yaz/doc/tools.html). I wrote about this last year on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12897 but I didn't go any further with it as it would be nice to make some more logical changes across the board... but feel free to make a patch to fix this particular case. -- Locally, I've done the following to solve this problem: Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- See Also| |http://bugs.koha-community. | |org/bugzilla3/show_bug.cgi? | |id=12897 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #2 from Barton Chittenden <barton@bywatersolutions.com> --- (In reply to David Cook from comment #1)
Hey Barton, I can explain the cause (and solution).
Check out "ccl.properties":
Date-of-publication 1=31 r=r yr Date-of-publication pubdate Date-of-publication
Date-of-acquisition 1=32 acqdate Date-of-acquisition
st-numeric 4=109 r=o st-name-normalized 4=101
If you look at the Zebra docs, you'll see that r=o and r=r are special attributes for doing range searches (http://www.indexdata.com/yaz/doc/tools.html).
I wrote about this last year on http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=12897 but I didn't go any further with it as it would be nice to make some more logical changes across the board... but feel free to make a patch to fix this particular case.
--
Locally, I've done the following to solve this problem:
Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition
Ok, this is from my ccl.properties: Date-of-acquisition 1=32 Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition Given an item where acqdate is 2011-09-07, search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-07 works, but querying the entire month from 2011-09-01 to 2011-09-30 does not: search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30" Returns no results. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #3 from David Cook <dcook@prosentient.com.au> --- (In reply to Barton Chittenden from comment #2)
Ok, this is from my ccl.properties:
Date-of-acquisition 1=32 Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition
Given an item where acqdate is 2011-09-07,
search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-07
works, but querying the entire month from 2011-09-01 to 2011-09-30 does not:
search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30"
Returns no results.
Barton, are you using the advanced search or the regular search box? It looks like the advanced search to me. The problem I see is that your query is being wrapped in double quotation marks. No results: /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q="2010-01-01+-+2015-01-01"&idx=kw&idx=kw&sort_by=relevance Lots of results: /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q=2010-01-01+-+2015-01-01&idx=kw&idx=kw&sort_by=relevance Here are two examples of it working in the staff client and opac when using free-form CCL queries: /cgi-bin/koha/catalogue/search.pl?q=acqdate%2Cst-date-normalized%3A2010-01-01+-+2015-01-01 /cgi-bin/koha/opac-search.pl?q=acqdate%2Cst-date-normalized%3A2010-01-01+-+2015-01-01&branch_group_limit= -- I've seen this sort of problem before on Bywater Koha sites... I just tried using the Advanced Search in Koha master and I got the following URL, which matches my working URL above. /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q=2010-01-01+-+2015-01-01&idx=kw&idx=kw&sort_by=relevance Are you trying this query on the Koha used by Bywater or the Koha master branch? I'm guessing Bywater has a local patch which quotes values and that's creating the problem. I'm going to poke around a bit more with yaz-client to see if I can find out more... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #4 from David Cook <dcook@prosentient.com.au> --- Z> f acqdate,st-date-normalized=2010-01-01 - 2015-01-01 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 9644, setno 2 SearchResult-1: term=2010-01-01 cnt=11758, term=2015-01-01 cnt=36059 records returned: 0 Elapsed: 0.179575 Z> f acqdate,st-date-normalized="2010-01-01 - 2015-01-01" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 3 SearchResult-1: term=2010-01-01 - 2015-01-01 cnt=0 records returned: 0 Elapsed: 0.000754 It's because "2010-01-01 - 2015-01-01" is being treated as a single term when it's supposed to be a range according to the CCL grammar. http://www.indexdata.com/yaz/doc/tools.html#ccl.syntax Elements ::= '(' CCL-Find ')' | Set | Terms | Qualifiers Relation Terms | Qualifiers Relation '(' CCL-Find ')' | Qualifiers '=' string '-' string -- Elements is either a recursive definition, a result set reference, a -- list of terms, qualifiers followed by terms, qualifiers followed -- by a recursive definition or qualifiers in a range (lower - upper). A syntactically correct query would be the following: acqdate,st-date-normalized=2010-01-01 - 2015-01-01 Because it's: qualifiers '=' string '-' string -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #5 from David Cook <dcook@prosentient.com.au> --- You might notice different tokenizing behaviours depending on your searches, and that's down to default.idx and using different "charmap" files for different index types (ie registers). We've already observed that "acqdate,st-date-normalized" with double quotes uses the value as a single token. Z> f acqdate,st-date-normalized="2010-01-01 - 2015-01-01" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 38 SearchResult-1: term=2010-01-01 - 2015-01-01 cnt=0 records returned: 0 Elapsed: 0.000856 Z> f acqdate,st-date-normalized=2010-01-01 - 2015-01-01 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 9644, setno 39 SearchResult-1: term=2010-01-01 cnt=11758, term=2015-01-01 cnt=36059 records returned: 0 Elapsed: 0.029800 However, "pubdate,st-numeric" tokenizes everything when using double quotes. Z> f pubdate,st-numeric="2010 - 2015" Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 0, setno 36 SearchResult-1: term=2010 cnt=1059, term=- cnt=167, term=2015 cnt=730 records returned: 0 Elapsed: 0.033589 Z> f pubdate,st-numeric=2010 - 2015 Sent searchRequest. Received SearchResponse. Search was a success. Number of hits: 5066, setno 37 SearchResult-1: term=2010 cnt=5068, term=2015 cnt=24660 records returned: 0 Elapsed: 0.093974 -- In the first two searches, we're using the date register: # Date # Used if structure=date (@attr 4=5) index d completeness 0 charmap @ Whereas with the second one, we're using the numeric register: # Numeric index # Used if structure=numeric (@attr 4=109) index n completeness 0 charmap numeric.chr As per the docs at http://www.indexdata.com/zebra/doc/character-map-files.html, "charmap @" means no normalization and no tokenization. This isn't just specific to the date register. It's also the case for "y" and "0". -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #6 from David Cook <dcook@prosentient.com.au> --- Just noticed that you had two different URLs... search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-07 search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30" Either you added the double quotes or they're inserted by your Koha? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #7 from Barton Chittenden <barton@bywatersolutions.com> --- (In reply to David Cook from comment #3)
(In reply to Barton Chittenden from comment #2)
Ok, this is from my ccl.properties:
Date-of-acquisition 1=32 Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition
Given an item where acqdate is 2011-09-07,
search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-07
works, but querying the entire month from 2011-09-01 to 2011-09-30 does not:
search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30"
Returns no results.
Barton, are you using the advanced search or the regular search box? It looks like the advanced search to me.
The problem I see is that your query is being wrapped in double quotation marks.
No results: /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q="2010- 01-01+-+2015-01-01"&idx=kw&idx=kw&sort_by=relevance
Lots of results: /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q=2010-01- 01+-+2015-01-01&idx=kw&idx=kw&sort_by=relevance
Here are two examples of it working in the staff client and opac when using free-form CCL queries: /cgi-bin/koha/catalogue/search.pl?q=acqdate%2Cst-date-normalized%3A2010-01- 01+-+2015-01-01 /cgi-bin/koha/opac-search.pl?q=acqdate%2Cst-date-normalized%3A2010-01-01+- +2015-01-01&branch_group_limit=
--
I've seen this sort of problem before on Bywater Koha sites...
I just tried using the Advanced Search in Koha master and I got the following URL, which matches my working URL above. /cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q=2010-01- 01+-+2015-01-01&idx=kw&idx=kw&sort_by=relevance
Are you trying this query on the Koha used by Bywater or the Koha master branch? I'm guessing Bywater has a local patch which quotes values and that's creating the problem.
I'm going to poke around a bit more with yaz-client to see if I can find out more...
Actually, I put the quotes in the URL by hand. When I search using the advanced search screen, the CCL query acqdate,st-date-normalized=2010-01-01 - 2015-01-01 Is parsed to search.pl?idx=kw&q=acqdate%2Cst-date-normalized%3D2010-01-01+-+2015-01-01&op=and&idx=kw&op=and&idx=kw&sort_by=relevance And acqdate,st-date-normalized="2010-01-01 - 2015-01-01" becomes search.pl?idx=kw&q=acqdate%2Cst-date-normalized%3D%222010-01-01+-+2015-01-01%22&op=and&idx=kw&op=and&idx=kw&sort_by=relevance I was essentially trying to short-circuit the parser by composing the URLs by hand. The quotes in the URL are a red herring anyway: Neither search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30" nor search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-01+-+2011-09-30 return results. I'm going to try applying this patch to master to see if I get different results. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #8 from Barton Chittenden <barton@bywatersolutions.com> --- I just checked the virtual machine that I have this running on -- it *is* running on master -- version 3.21.00.028. I've only made a single change against that: diff --git a/etc/zebradb/ccl.properties b/etc/zebradb/ccl.properties index 93ae8ec..fdd8eec 100644 --- a/etc/zebradb/ccl.properties +++ b/etc/zebradb/ccl.properties @@ -344,6 +344,7 @@ pubdate Date-of-publication #Date-acquisition 32 The date when a document was 541$d # acquired. Date-of-acquisition 1=32 +Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition #Date/time added to 1011 The date and time that a 008/00-05 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #9 from David Cook <dcook@prosentient.com.au> --- (In reply to Barton Chittenden from comment #7)
The quotes in the URL are a red herring anyway:
I can assure you that they're not. The quotes are a problem too.
Neither
search.pl?idx=acqdate%2Cst-date-normalized&q="2011-09-01+-+2011-09-30"
nor
search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-01+-+2011-09-30
return results.
I'm going to try applying this patch to master to see if I get different results.
Well, that's rather strange. It's definitely working on a number of 3.14 installs. Hmm... you're right... it's not working in master. It seemed to be working when I had an acqdate with 2011-09-01, but then I changed it to 2011-09-02 in the item, and now it's clearly not working. The query works in yaz-client, so it's clear that Koha is doing something naughty. *looks at the logs* Holy... Barton, I think you've uncovered a much larger bug. Let me guess... you're not using the first box in the advanced search, are you? It works for me when I use the first box as "Acquisition date (yyyy-mm-dd)", but if I leave the first two boxes as "Keyword" and I use the third box as "Acquisition date (yyyy-mm-dd)", it won't work. Check your logs to see what's actually coming out of buildQuery. -- Also, a note on your first comment: Results of search for 'acqdate,st-date-normalized: >2015-08-01' No results found! If you check your logs, you'll see that it says the following: WARNING: query problem with acqdate,st-date-normalized=> 2011-08-01 ZOOM error 10014 "CCL parsing error" (addinfo: "Bad relation") from diag-set 'ZOOM' While the documentation uses "yr,st-numeric=>2000", that's actually a bad example as it produces the same error: WARNING: query problem with yr,st-numeric=>2000 ZOOM error 10014 "CCL parsing error" (addinfo: "Bad relation") from diag-set 'ZOOM' I keep meaning to re-write the search documentation for Koha... it's really not very accurate... You know what would work in Koha? ccl=acqdate,st-date-normalized > 2011-08-30 Or in yaz-client: acqdate,st-date-normalized > 2011-08-30 The relation doesn't work properly in Koha, because we're not parsing the query properly. "buildQuery" is a nightmare which butchers queries and turns them into pseudo-CCL. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #10 from David Cook <dcook@prosentient.com.au> --- Actually, the problems I'm encountering with the advanced search are different based on the URLs you're showing me... give me a few more minutes... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #11 from David Cook <dcook@prosentient.com.au> --- (In reply to Barton Chittenden from comment #8)
I just checked the virtual machine that I have this running on -- it *is* running on master -- version 3.21.00.028.
I've only made a single change against that:
diff --git a/etc/zebradb/ccl.properties b/etc/zebradb/ccl.properties index 93ae8ec..fdd8eec 100644 --- a/etc/zebradb/ccl.properties +++ b/etc/zebradb/ccl.properties @@ -344,6 +344,7 @@ pubdate Date-of-publication #Date-acquisition 32 The date when a document was 541$d # acquired. Date-of-acquisition 1=32 +Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition
#Date/time added to 1011 The date and time that a 008/00-05
Looking at this again... that doesn't look right. You're defining the "Date-of-acquisition" alias twice. It should be: Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition Not: Date-of-acquisition 1=32 Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition That said, I just did a test and it seems like it doesn't matter... it appears that the second alias definition overrides the first. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #12 from David Cook <dcook@prosentient.com.au> --- Sorry for all the comments! I definitely have this working in master, when I use the following URL: search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-01+-+2011-09-30 I didn't need to restart Zebra or re-index either to make it work. I just change the ccl.properties file. Here's the entry for the working query in my logs: [Wed Sep 30 15:08:25 2015] search.pl: QUERY:acqdate,st-date-normalized=2011-09-01 - 2011-09-30 Another reason it might not be working... are you sure that you actually have anything indexed into acqdate? I suppose it must have something in it if the following URL works: search.pl?idx=acqdate%2Cst-date-normalized&q=2011-09-07 -- Let's see... remaining guesses... perhaps you're not changing the correct ccl.properties file. My advice would be to do the following: 1) Check your logs to see what buildQuery is producing 2) Try your query in yaz-client (following the advice at http://wiki.koha-community.org/wiki/Troubleshooting_Zebra#Manually_searching...) -- I assure you that this should work. I think it's just a configuration problem on your end. If you're using a Gitified Koha, you'll have problems, because Gitified Koha doesn't handle Zebra changes I believe. If you're using a Gitified Koha... you would need to change /etc/koha/zebradb/ccl.properties because it won't be using the ccl.properties within your Git since it's not installed anywhere unless you've changed the koha-conf.xml for that instance. Sorry again for all the words. I don't use Gitify or Debian for Koha, so I do things a bit differently, but the Zebra configuration works. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #13 from David Cook <dcook@prosentient.com.au> --- Just fired up my old Debian VM and I'm noticing something mighty peculiar... [Wed Sep 30 15:34:26 2015] [error] [client ::1] [Wed Sep 30 15:34:26 2015] search.pl: QUERY:2014-03-24 - 2014-03-27 at /home/david/koha/C4/Search.pm line 1609., referer: http://localhost:2051/cgi-bin/koha/catalogue/search.pl [Wed Sep 30 15:34:26 2015] [error] [client ::1] [Wed Sep 30 15:34:26 2015] search.pl: QUERY CGI:idx=acqdate%2Cst-date-normalized&q=2014-03-24%20-%202014-03-27 at /home/david/koha/C4/Search.pm line 1610., referer: http://localhost:2051/cgi-bin/koha/catalogue/search.pl [Wed Sep 30 15:34:26 2015] [error] [client ::1] [Wed Sep 30 15:34:26 2015] search.pl: QUERY DESC:acqdate,st-date-normalized: 2014-03-24 - 2014-03-27 at /home/david/koha/C4/Search.pm line 1611., referer: http://localhost:2051/cgi-bin/koha/catalogue/search.pl I also wound up at the following URL: search.pl?idx=acqdate&q=2014-03-24+-+2014-03-27&idx=kw&idx=kw&sort_by=relevance Sure enough... it's not working even with the ccl.properties modification. However, I am able to get it to work in yaz-client, so I'm thinking it's something weird in Koha... That's an old verison of Koha though... I'll try master... By the way, I had to add "SetEnv DEBUG 1" in order to get any of this in my logs... -- I'm trying to update my Git, but I have 1.5 years worth of commits to download, so it's taking a while... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #14 from David Cook <dcook@prosentient.com.au> --- (In reply to Barton Chittenden from comment #8)
I just checked the virtual machine that I have this running on -- it *is* running on master -- version 3.21.00.028.
I've only made a single change against that:
diff --git a/etc/zebradb/ccl.properties b/etc/zebradb/ccl.properties index 93ae8ec..fdd8eec 100644 --- a/etc/zebradb/ccl.properties +++ b/etc/zebradb/ccl.properties @@ -344,6 +344,7 @@ pubdate Date-of-publication #Date-acquisition 32 The date when a document was 541$d # acquired. Date-of-acquisition 1=32 +Date-of-acquisition 1=Date-of-acquisition r=o acqdate Date-of-acquisition
#Date/time added to 1011 The date and time that a 008/00-05
Ok, since I'm insatiably curious, I spun up a Debian Wheezy virtual machine to run a Gitified Koha. It's on version 3.21.00.030. In /etc/koha/zebradb/ccl.properties I have the following entry: Date-of-acquisition 1=32 r=o acqdate Date-of-acquisition NOTE: I added the r=o Here's the URL I'm getting: http://localhost:2051/cgi-bin/koha/catalogue/search.pl?idx=acqdate%2Cst-date-normalized&q=2014-03-24+-+2014-03-27&idx=kw&idx=kw&sort_by=relevance I have two bib records each with an item with a Date Acquired within that date range, and I'm getting search results that include both those bib records. -- Now that I look at your original post again... editing "etc/zebradb/ccl.properties" in the Git directory won't do anything. That file doesn't get used at all. If you're on Debian and you're using a Gitified install, you want "/etc/koha/zebradb/ccl.properties". It's the configuration file used by the packages, but that's what a Gitified Koha relies upon. If you dont' want to modify that, you're going to have to do a manual install of Koha using the "single" option and then do a "make upgrade" every time you make changes to "etc/zebradb/ccl.properties" in your Git. Anyway, if you change the "/etc/koha/zebradb/ccl.properties" file, I bet it'll work for you. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #15 from Barton Chittenden <barton@bywatersolutions.com> --- Created attachment 42980 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=42980&action=edit Bug 14861: Change acqdate to allow date ranges. Use 'r=o' to in ccl.properties enable acqudate date range searches of the form YYYY-MM-DD - yyyy-mm-dd -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #16 from Barton Chittenden <barton@bywatersolutions.com> --- (In reply to Barton Chittenden from comment #15)
Created attachment 42980 [details] [review] Bug 14861: Change acqdate to allow date ranges.
Use 'r=o' to in ccl.properties enable acqudate date range searches of the form
YYYY-MM-DD - yyyy-mm-dd
Test plan Prerequisites: Make sure that you have an item with a valid dateaccessioned, and that the bib is indexed in zebra. For the purposes of explanation, I'm going to use the date '2011-09-07' 1) Go to advanced search in the staff client and choose 'Acquisition date (yyyy-mm-dd)' 2) Enter 2011-09-07 (or the date of your choice). 3) Click the search button - you should get your item in the search results. 4) Return to the advanced search screen and select Acquisition date again. 5) Enter a start and end date in the text field separated by ' - ', e.g. 2011-09-01 - 2011-09-30 6) Click the search button -- this will return no results. 7) Apply the patch and copy etc/zebradb/ccl.properties to whatever directory is specified by $KOHA_CONF 8) Re-try step 5 -- this should return results. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Assignee|gmcharlt@gmail.com |barton@bywatersolutions.com -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #17 from David Cook <dcook@prosentient.com.au> --- I don't think we needed to change "1=32" to "1=Date-of-acquisition", but it's a trivial difference, so no worries. Sign off to follow... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42980|0 |1 is obsolete| | --- Comment #18 from David Cook <dcook@prosentient.com.au> --- Created attachment 42988 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=42988&action=edit Bug 14861: Change acqdate to allow date ranges. Use 'r=o' to in ccl.properties enable acqudate date range searches of the form YYYY-MM-DD - yyyy-mm-dd Signed-off-by: David Cook <dcook@prosentient.com.au> Used the test plan from Bugzilla, and it works as described. -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |jonathan.druart@bugs.koha-c | |ommunity.org --- Comment #19 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- I am not familiar with ccl.properties, but there is a st-numeric 4=109 r=o Does - st-date-normalized 4=5 + st-date-normalized 4=5 r=o could do the trick for all date indexes? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #20 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #19)
I am not familiar with ccl.properties, but there is a st-numeric 4=109 r=o
Does - st-date-normalized 4=5 + st-date-normalized 4=5 r=o could do the trick for all date indexes?
Yes! That is probably a better idea! I was suggesting on bug 12897 that we use ranges for all date indexes, and I think that would be the way to do it. What's the best way to move forward? Should I provide an alternative patch? Perhaps Barton can sign that one off, and Jonathan you can still QA? -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #21 from Barton Chittenden <barton@bywatersolutions.com> --- (In reply to David Cook from comment #20)
(In reply to Jonathan Druart from comment #19)
I am not familiar with ccl.properties, but there is a st-numeric 4=109 r=o
Does - st-date-normalized 4=5 + st-date-normalized 4=5 r=o could do the trick for all date indexes?
Yes! That is probably a better idea! I was suggesting on bug 12897 that we use ranges for all date indexes, and I think that would be the way to do it.
What's the best way to move forward? Should I provide an alternative patch? Perhaps Barton can sign that one off, and Jonathan you can still QA?
That works by me. --Barton -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Katrin Fischer <katrin.fischer@bsz-bw.de> changed: What |Removed |Added ---------------------------------------------------------------------------- Severity|enhancement |normal CC| |katrin.fischer@bsz-bw.de -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #22 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Yep, if it works, let's do it for all date indexes :) -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #23 from David Cook <dcook@prosentient.com.au> --- (In reply to Jonathan Druart from comment #22)
Yep, if it works, let's do it for all date indexes :)
I suppose I should clarify this a bit... In ccl.properties, we create the following mapping: "st-date-normalized 4=5" This associates a CCL qualifier name with a Bib-1 structure attribute. Internally in Zebra, the Bib-1 attribute "4=5" is mapped to the Date "d" register. http://www.indexdata.com/zebra/doc/querymodel-zebra.html#querymodel-pqf-apt-... If we search "biblio-zebra-indexdefs.xsl" for MARC21, we find that "Date-of-acquisition" is actually the only index defined in the Date "d" register. It's a little better for UNIMARC, as it also has "onloan" added to the "d" register. What that means is that "st-date-normalized" can really only be used for "Date-of-acquisition" with MARC21/NORMARC, and "Date-of-acquisition" and "onloan" for UNIMARC. -- Of course, there are lots of other MARC fields where we store ISO formatted dates, but we put them in the "w" register, so that they can be found using "kw,wrdl" queries it seems. We probably under-use the various registers available. The only index using the "y" register is "pubdate" in MARC21. UNIMARC has a few more although I'm not sure whether they're used correctly as I'm not familiar with the format. The "y" register is only suitable for "YYYY" strings. The only way to access the "y" register is by using "st-year" as well. "st-numeric" accesses the "n" register which seems to be relied upon a lot in Koha. -- In any case, I'll add a patch to add "r=o" to "st-date-normalized", even though it will only really affect the advanced search for acquisition date (and any CCL queries that are formed by hand). In the future, we could look at adding other indexes to the "d" register if necessary... -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 David Cook <dcook@prosentient.com.au> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Needs Signoff -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 --- Comment #24 from David Cook <dcook@prosentient.com.au> --- Created attachment 43151 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=43151&action=edit Bug 14861 - [ALTERNATE] Accession date comparison does not work in advanced search _Test plan_ Prerequisites: Make sure that you have an item with a valid dateaccessioned, and that the bib is indexed in zebra. For the purposes of explanation, I'm going to use the date '2011-09-07' 1) Go to advanced search in the staff client and choose 'Acquisition date (yyyy-mm-dd)' 2) Enter 2011-09-07 (or the date of your choice). 3) Click the search button - you should get your item in the search results. 4) Return to the advanced search screen and select Acquisition date again. 5) Enter a start and end date in the text field separated by ' - '. For example: 2011-09-01 - 2011-09-30 6) Click the search button -- this will return no results. 7) Apply the patch and copy etc/zebradb/ccl.properties to whatever directory is specified by the koha-conf.xml referenced by $KOHA_CONF. 8) Try the search again -- this will return the expected results -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Marc Véron <veron@veron.ch> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |veron@veron.ch -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Heather Braum <hbraum@nekls.org> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |hbraum@nekls.org -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #42988|0 |1 is obsolete| | -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Needs Signoff |Signed Off -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Barton Chittenden <barton@bywatersolutions.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #43151|0 |1 is obsolete| | --- Comment #25 from Barton Chittenden <barton@bywatersolutions.com> --- Created attachment 43255 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=43255&action=edit Bug 14861 - [SIGNED OFF] Accession date comparison does not work in advanced search _Test plan_ Prerequisites: Make sure that you have an item with a valid dateaccessioned, and that the bib is indexed in zebra. For the purposes of explanation, I'm going to use the date '2011-09-07' 1) Go to advanced search in the staff client and choose 'Acquisition date (yyyy-mm-dd)' 2) Enter 2011-09-07 (or the date of your choice). 3) Click the search button - you should get your item in the search results. 4) Return to the advanced search screen and select Acquisition date again. 5) Enter a start and end date in the text field separated by ' - '. For example: 2011-09-01 - 2011-09-30 6) Click the search button -- this will return no results. 7) Apply the patch and copy etc/zebradb/ccl.properties to whatever directory is specified by the koha-conf.xml referenced by $KOHA_CONF. 8) Try the search again -- this will return the expected results Signed-off-by: Barton Chittenden <barton@bywatersolutions.com> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|Signed Off |Passed QA -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Jonathan Druart <jonathan.druart@bugs.koha-community.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #43255|0 |1 is obsolete| | --- Comment #26 from Jonathan Druart <jonathan.druart@bugs.koha-community.org> --- Created attachment 43420 --> http://bugs.koha-community.org/bugzilla3/attachment.cgi?id=43420&action=edit Bug 14861 - [SIGNED OFF] Accession date comparison does not work in advanced search _Test plan_ Prerequisites: Make sure that you have an item with a valid dateaccessioned, and that the bib is indexed in zebra. For the purposes of explanation, I'm going to use the date '2011-09-07' 1) Go to advanced search in the staff client and choose 'Acquisition date (yyyy-mm-dd)' 2) Enter 2011-09-07 (or the date of your choice). 3) Click the search button - you should get your item in the search results. 4) Return to the advanced search screen and select Acquisition date again. 5) Enter a start and end date in the text field separated by ' - '. For example: 2011-09-01 - 2011-09-30 6) Click the search button -- this will return no results. 7) Apply the patch and copy etc/zebradb/ccl.properties to whatever directory is specified by the koha-conf.xml referenced by $KOHA_CONF. 8) Try the search again -- this will return the expected results Signed-off-by: Barton Chittenden <barton@bywatersolutions.com> Signed-off-by: Jonathan Druart <jonathan.druart@bugs.koha-community.org> -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Tomás Cohen Arazi <tomascohen@gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |tomascohen@gmail.com Status|Passed QA |Pushed to Master --- Comment #27 from Tomás Cohen Arazi <tomascohen@gmail.com> --- Patch pushed to master. Thanks David! -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Chris Cormack <chris@bigballofwax.co.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |chris@bigballofwax.co.nz Status|Pushed to Master |Pushed to Stable --- Comment #28 from Chris Cormack <chris@bigballofwax.co.nz> --- Pushed to 3.20.x will be in 3.20.5 -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Fridolin SOMERS <fridolin.somers@biblibre.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |fridolin.somers@biblibre.co | |m -- You are receiving this mail because: You are watching all bug changes.
http://bugs.koha-community.org/bugzilla3/show_bug.cgi?id=14861 Liz Rea <liz@catalyst.net.nz> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |liz@catalyst.net.nz --- Comment #29 from Liz Rea <liz@catalyst.net.nz> --- Pushed to 3.18.x, is in 3.18.12. -- You are receiving this mail because: You are watching all bug changes.
participants (1)
-
bugzilla-daemon＠bugs.koha-community.org