Probably best to discuss some of these issues here...
On 04/11/13 16:50, Apache Bloodhound wrote:
#654: Rows in ticket query result set not sorted by column
---------------------------+-----------------------------------
Reporter: olemis | Owner: gjm
Type: defect | Status: accepted
Priority: blocker | Milestone: Release 8
Component: multiproduct | Version:
Resolution: | Keywords: ticket query, sorting
---------------------------+-----------------------------------
Comment (by olemis):
Replying to [comment:8 gjm]:
> I've been considering this one for a while now. The immediate problem is
that lists of enums (Type, Status, Resolution, Priority and Severity for
example) are not available as the query to select them is restricted to
the product that they are performed in. This makes a bit less sense at the
top level where there are none.
>
> There are a number of ways to deal with this, one of which includes
providing an extra variable on the env object to determine whether to
force a db_direct_query and decorate the !AbstractEnum.select method to
choose when no product is selected.
I do not understand , I've tried something similar to this and still query
does not sort tickets by ID are why do we need to add an extra attribute
in the environment object ?
Certainly it is not clear that this will fix the issue Olemis
highlighted but it addresses the ability to order by enum fields. I
could of course create a new ticket to separate out this work. The extra
attribute is one of a number of possible solutions. This would be one
way of swapping to the db_direct_query without modifying trac code.
Unfortunately, as a query can be expected to get multiple versions of
enums back, there still needs to be a change to deduplicate - something
like this somewhere around line 362 of trac/trac/ticket/api.py:
unique = set()
options = [o for o in options if o not in unique and not unique.add(o)]
Perhaps it would be nicer for the work of this to be handed over to the
database.
The issue mentioned in comment:5 is just about label , I mean , column
header is ''Ticket'' whereas values in column are priorities .
I looked to fix based on the observation from Olemis that "Priority
column header is missing , replaced by Ticket" on bh-demo1 could be
related. I don't hold out a particular hope of this. I am not convinced
that I have seen the actual issue that was raised.
> This would look something like:
> {{{
> #!python
> import copy
> from trac.ticket import model
>
> from functools import wraps
>
> def direct_query_override(f):
> @classmethod
> @wraps(f)
> def decorator(cls, env, *args, **kwargs):
> kwargs.pop('db', None)
> denv = copy.copy(env)
> if not getattr(denv, 'product', None):
> denv._db_direct_override = True
> return f.__get__(True).im_func(cls, denv, *args, **kwargs)
> return decorator
>
> model.AbstractEnum.select =
direct_query_override(model.AbstractEnum.select)
> }}}
>
I'm not sure about this ... IMO we better keep them scoped to a given
product and add a separate method to list all enums in all products ,
`select_all` ? Notice that there's a case for retrieving all enums in
different products .
I think we should be able to appeal to the parent environment for its
list when that is appropriate but I am not averse to providing the
ability a little more directly. Currently queries seem to be fully
scoped anyway so you already need to use a global query for
cross-product queries.
> That still leaves a bit to do about including:
> * duplicate removal
+
> * restricting returned values based on permissions
+
> * decide whether we care that enums may end up with different
priorities in different products
Should be important , maybe for highlighting .
Well, sort of - the ordering (and therefore highlighting) is simply
based on the numeric value. Of course this simplicity means that there
may be problems to solve when users expect to get equivalence of
priorities across products with different priority enum sets with common
members but there is only so much we can do. It is probably a little
premature to solve the problem but we could:
* scale the values by the number in each list
* allow for admins to define gaps in the enum lists
* make it easy to apply enum schemes to multiple products or for
products to share definitions
I don't think any of those fully solve the problem though.
Cheers,
Gary
