Opened 17 years ago
Closed 16 years ago
#5998 closed defect (fixed)
Add support for grouping, ordering, and column sets to default queries
Reported by: | Owned by: | Remy Blank | |
---|---|---|---|
Priority: | normal | Milestone: | 0.11.2 |
Component: | report system | Version: | 0.11-stable |
Severity: | normal | Keywords: | query review |
Cc: | dkg-debian.org@…, jashugan@…, jorge@…, me@… | Branch: | |
Release Notes: | |||
API Changes: | |||
Internal Changes: |
Description (last modified by )
In the trac.ini file there's options for the default query strings:
[query] default_anonymous_query = status!=closed&cc~=$USER default_query = status!=closed&owner=$USER
I'd like to see support for grouping, ordering, and column options added for these default queries. For example something like
default_query = status!=closed&owner=$USER&group=status&order=priority&col=id|summary|type or default_query = status!=closed&owner=$USER&group=status&order=priority&col=id&col=summary&col=type
Attachments (4)
Change History (17)
comment:1 by , 17 years ago
Description: | modified (diff) |
---|---|
Keywords: | query added |
Milestone: | → 0.11.1 |
Type: | enhancement → defect |
Version: | → devel |
comment:2 by , 17 years ago
Cc: | added |
---|
I'd like to see this also, if possible. It's odd that ordering seems to work from a query:order=summary style link, but not from default_query
. That suggests maybe there could be better code reuse?
comment:3 by , 17 years ago
Cc: | added |
---|
follow-up: 6 comment:5 by , 16 years ago
Cc: | added |
---|---|
Keywords: | review added |
Version: | devel → 0.11-stable |
okay, I don't know why you can't see the patch if you click on it, but if you download it it works.
it's patched against .11-stable.
comment:6 by , 16 years ago
Replying to Stephen Prater <me@stephenprater.com>:
okay, I don't know why you can't see the patch if you click on it, but if you download it it works.
No it's not a proper patch:
File to patch: trac/ticket/query.py patching file trac/ticket/query.py patch: **** malformed patch at line 29: @@ -759,16 +777,28 @@
it's patched against .11-stable.
Besides your added code contains a mix of space and tabs, please don't use tabs (see PEP:0008, look for Tabs or Spaces?).
by , 16 years ago
Attachment: | query.2.patch added |
---|
comment:7 by , 16 years ago
well, here it cleaned up. this time i patched it against trunk.
it's definitely sort of hacky - there's problems with the "rows" vs "row" in the query language vs. the request, and i'm not sure that "faking" request arguments is really the best approach here. It seemed like the least involved.
The point being - you should definitely view this as a starting point, and not something final. I hacked it in because I needed the functionality, and I thought I'd share.
by , 16 years ago
Attachment: | 5998-extended-default-query-r7524.patch added |
---|
Patch against 0.11-stable allowing query strings in default custom queries
comment:8 by , 16 years ago
Owner: | changed from | to
---|
The patch above extends the default query trac.ini
options to also accept query strings starting with ?
, in the same way as the query:
wiki syntax. This allows setting up a custom query and copy/pasting the query part of the URL directly into trac.ini
.
Comments?
follow-up: 10 comment:9 by , 16 years ago
The approach looks good, but I wonder why you encode the keys into utf-8 (the name = name.encode('utf-8')
part)?
comment:10 by , 16 years ago
Replying to cboos:
I wonder why you encode the keys into utf-8 (the
name = name.encode('utf-8')
part)?
Because the constraints
for the query are used as kwargs somewhere in Query
(more specifically here), and you can't have unicode keys for that.
I could also do the conversion in Query.get_href()
, but req.args
has exactly this structure: utf-8 keys, unicode values (well, at least str
keys, unicode
values; I'm not sure the URL is encoded in utf-8, but path_info
is decoded as utf-8, so I figured the query string would also have the same encoding).
follow-up: 12 comment:11 by , 16 years ago
I see, thanks!
The Query.from_string
uses field = str(field)
for a similar purpose, so we might want to do the same here. Looks like this encoding is expected by the user of self.constraints
, in unicode_urlencode
(reached from Href.__call__
), so everything is fine ;-)
comment:12 by , 16 years ago
Replying to cboos:
The
Query.from_string
usesfield = str(field)
for a similar purpose, so we might want to do the same here.
Did you mean something like this?
-
trac/ticket/query.py
diff --git a/trac/ticket/query.py b/trac/ticket/query.py
a b 146 146 for val in values.split('|'): 147 147 val = neg + mode + val # add mode of comparison 148 148 processed_values.append(val) 149 try: 150 field = str(field) 151 if field in kw_strs: 152 kw[field] = processed_values[0] 153 elif field in kw_arys: 154 kw[field] = processed_values 155 elif field in kw_bools: 156 kw[field] = True 157 elif field == 'col': 158 cols.extend(processed_values) 159 else: 160 constraints[field] = processed_values 161 except UnicodeError: 162 pass # field must be a str, see `get_href()` 149 if isinstance(field, unicode): # field must be a str, 150 field = field.encode('utf-8') # see `get_href()` 151 if field in kw_strs: 152 kw[field] = processed_values[0] 153 elif field in kw_arys: 154 kw[field] = processed_values 155 elif field in kw_bools: 156 kw[field] = True 157 elif field == 'col': 158 cols.extend(processed_values) 159 else: 160 constraints[field] = processed_values 163 161 report = constraints.pop('report', None) 164 162 report = kw.pop('report', report) 165 163 return cls(env, report, constraints=constraints, cols=cols, **kw)
comment:13 by , 16 years ago
Milestone: | 0.11.3 → 0.11.2 |
---|---|
Resolution: | → fixed |
Status: | new → closed |
Patch applied in [7553].
Right, this should also support grouping and specifying the columns to be complete.