When searching in a date column, date ranges can be
entered in two formats.
1 - long format: From <start date> to <end date>
2 - short format: <start date>;<end date>

If a query is saved with a date range in long format,
recalling the query will show all issues within the
date range. But if the query was saved with a short
format date range, recalling the query will only show
those issues that match the start date. In the
database, the query is stored correct as <start
date>;<end date>, but when showing the query in the
search page, only the start date will be there.

Logged In: NO 

This smells like an SQL quoting issue. Which backend? 

Logged In: YES 
user_id=1080231

Our backend is MySQL, but I don't think it's an SQL issue.
And this is why: If I go to issue.search.html and fill in a
date like '2005-01-01;2005-12-31' for the creation date, add
a query name like 'all in 2005' then press search, the query
results are OK. If I now click on the new 'all in 2005'
query, only the issues from date '2005-01-01' are shown. If
I use the query.edit.html page and click on the 'edit' link
for query '2005-01-01', the issue.search.html page appears
again (as expected) but the creation date field only
contains '2005-01-01'. Looking at the stored query with a
MySQL client, the query contains
'&creation=2005-01-01;2005-12-31'. When I looked at the
server logging, I did note that the ';' in the creation date
is escaped (replaced by %3B) while the rest of the query in
the URL isn't escaped. I tried the query dirrectly within
the browser. The strangest thing is that it only works with
an escaped ';'.
- http://.../issue?...&creation=2005-01-01;2005-12-31
  This one only gives issues created on 2005-01-01
- http://.../issue?...&creation=2005-01-01%3B2005-12-31
  This one shows all issues within the range

Logged In: NO 

[richard here] 
 
Ah, *smacks forehead*, ";" is a special char in URLs. It separates 
the path and parameters components: 
 
  scheme://netloc/path;parameters?query#fragment 
 
though the ";" is appearing in the query section, so really 
shouldn't cause problems. Well, it needs to be quoted anyway. 
Not sure why it's not. 
 

Logged In: YES 
user_id=1080231

I hacked the query directly within mysql and changed the ';'
in the date range into '%3B', then tried the query in the
web interface again. Calling 'issue.search.html' will show
<start date>;<end date> as it should. Evenso does executing
the query return with the correct result. So I guess that
this bug can be solved by replacing any ';' with '%3B' 
before storing the query.
A simple patch for 'cgi/actions.py' could be (based on 0.7.11):

Index: cgi/actions.py
===================================================================
@@ -137,7 +137,7 @@
 
             # The [1:] strips off the '?' character, it
isn't part of the
             # query string.
-            url = req.indexargs_href('', {})[1:]
+            url = re.sub(';', '%3B', req.indexargs_href('',
{})[1:])
 
             key = self.db.query.getkey()
             if key:

Regards,
Marlon

Logged In: YES 
user_id=1080231

Hmm, not only cgi/action.py needs to be patched, but also
'cgi/templating.py' method 'indexargs_url' to make sure that
features like export csv do work to. This is the patch
(based on 0.7.11):

Index: cgi/templating.py
===================================================================
@@ -2033,12 +2033,12 @@
             for k,v in self.filterspec.items():
                 if not args.has_key(k):
                     if type(v) == type([]):
                         if isinstance(props[k],
hyperdb.String):
-                            l.append('%s=%s'%(k,
'%20'.join([q(i) for i in v])))
+                            l.append(re.sub(';', '%3B',
'%s=%s'%(k, '%20'.join([q(i) for i in v]))))
                         else:
-                            l.append('%s=%s'%(k,
','.join([q(i) for i in v])))
+                            l.append(re.sub(';', '%3B',
'%s=%s'%(k, ','.join([q(i) for i in v]))))
                     else:
-                        l.append('%s=%s'%(k, q(v)))
+                        l.append(re.sub(';', '%3B',
'%s=%s'%(k, q(v))))
         return '%s?%s'%(url, '&'.join(l))
     indexargs_href = indexargs_url

Regards,
Marlon

Logged In: YES 
user_id=8719

i suppose that string.replace() should be better than
re.sub() in this case

Logged In: NO 

[Richard here] 
I've not looked at the code, but perhaps we should be using 
urllib.urlquote, to catch *all* these special chars? If we *are* 
already using it, then we need to file a bug report so it gets fixed 
and catches *all* these special chars :) 
 

Logged In: YES 
user_id=6405

*cough*

I can't reproduce this in 0.7.11, and looking at the code, I can't see how 
you're having a problem. The indexargs_url (also known as _href) code 
clearly quotes the values used in filtering.

Well, except for the full-text search field, but I just fixed that :)

The ";" in the date search field was definitely quoted for me (and checking 
urllib.quote() it definitely quotes ";"). What version of Python are you 
using?

Logged In: YES 
user_id=1080231

Hi Richard,

Here is some info about our main server:
OS: Sushe Linux
Python: 2.3.3
RoundUp: 0.7.9

And this is our test server:
OS: Windows NT4
Python: 2.3.3
RoundUp: 0.7.11

We have this problems on both set-ups, and for both the
problem is solved when I make the two patches as I previous
posted.
Our tracker use framesets. We use 'indexargs_url' to pass
the query between the parent frame and its child. Mayby that
the escaped simicolon get lost somewhere between the two
frames. That would explain why it works for you and not for
us. Anyway, with the two patches we have a working situation
and even without those patches, then there is still the
working 'from <start date> to <end date>'.
So if this 'problem' is caused by our tracker, then please
feel free to close this issue without any changes to the
roundup code. The changes are small and it won't stress us
when we have to patch new roundup releases with our
'personal' patches. Don't worry, we still will love your
RoundUp ;)

Best regards,
Marlon