Logged In: YES 
user_id=469548

Well, maybe there is a way that isn't much of a pain and 
mostly leaves the current design alone. To achieve this, we'd 
need to implement filling in the form fields in the templates. 
However, this is inconsistent with the rest of roundup, which 
uses field() and other methods of HTMLProperty to achieve 
this. It also means there would be a lot of duplication in the 
issue.search template. The latter can be adressed by using 
METAL macro's, but to get the level of flexibility required we'd 
have to use tal:define to pass variables into the macro's, 
which
is ugly. Still, it works and is easy to implement.

Another option would be to use the methods of 
HTMLProperty, but this would require some changes to the 
design:

Instead of representing the query properties as an 
attribute 'url', use an instance of the Issue class that doesn't 
show up when using find(), list() or lookup() just like a retired 
node, and insert a 'filter' Link attribute to that node in the 
Query class, so the templates could access the methods of
HTMLProperty using 'query/filter/priority' for example.

Unfortunately, a Link property can only link to one class, so 
extending the above design for searching multiple classes 
wouldn't be easy. Also, that some nodes in the Issue class 
wouldn't really be Issues, but just filters for searching Issues 
seems ugly.

As using macro's and keeping the current design was a lot 
easier and didn't require major changes like the design above, 
I decided to go for the macro's (query-editing.diff):

- Totally reworked the issue.search template using new 
macros in 'page' and updated the category example in 
customization.txt to reflect these changes. I've tried to keep 
issue.search as simple as possible, while hiding the details of 
query editing in the macros.

- Changed HTMLRequest.updateFromUrl to set request.form 
to be a cgi.FieldStorage instead of a dictionary, to ensure 
request.form.getvalue() is always available.