Ticket #5998 (closed defect: fixed)
Add support for grouping, ordering, and column sets to default queries
| Reported by: | scottb@… | Owned by: | rblank |
|---|---|---|---|
| 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@… |
Description (last modified by cboos) (diff)
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
Change History
comment:1 Changed 3 years ago by cboos
- Keywords query added
- Version set to devel
- Type changed from enhancement to defect
- Description modified (diff)
- Milestone set to 0.11.1
comment:2 Changed 3 years ago by Daniel Kahn Gillmor <dkg-debian.org@…>
- Cc dkg-debian.org@… 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:4 Changed 2 years ago by jorge@…
- Cc jorge@… added
I am also waiting for this to be implemented.
comment:5 follow-up: ↓ 6 Changed 2 years ago by Stephen Prater <me@…>
- Cc me@… added
- Keywords review added
- Version changed from devel to 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 in reply to: ↑ 5 Changed 2 years ago by cboos
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?).
comment:7 Changed 2 years ago by Stephen Prater <me@…>
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.
Changed 2 years ago by rblank
- attachment 5998-extended-default-query-r7524.patch added
Patch against 0.11-stable allowing query strings in default custom queries
comment:8 Changed 2 years ago by rblank
- Owner changed from mgood to rblank
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?
comment:9 follow-up: ↓ 10 Changed 2 years ago by cboos
The approach looks good, but I wonder why you encode the keys into utf-8 (the name = name.encode('utf-8') part)?
comment:10 in reply to: ↑ 9 Changed 2 years ago by rblank
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).
comment:11 follow-up: ↓ 12 Changed 2 years ago by cboos
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 in reply to: ↑ 11 Changed 2 years ago by rblank
Replying to cboos:
The Query.from_string uses field = 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 Changed 2 years ago by rblank
- Status changed from new to closed
- Resolution set to fixed
- Milestone changed from 0.11.3 to 0.11.2
Patch applied in [7553].



Right, this should also support grouping and specifying the columns to be complete.