Alec Thomas wrote:
I've completed a fair chunk of these changes. A summary of what is done
and what is pending is available at:
http://projects.edgewall.com/trac/wiki/WorkFlow
I've also documented the available field options.
The query unit tests are failing because the generated SQL depends on
the order in which fields are encountered. As they are now encountered
in the order they are to be displayed, this results in different SQL.
Question is, is this an issue? The query code arbitrarily truncates the
columns to to 7, which is currently dropping the "owner" field, plus
others. It seems that this doesn't matter however as the owner column
is not displayed. Is this correct? If so, I'll just modify the unit
tests accordingly.
I already went into this painful process while adding the ticket_type to
the lot.
I think it's better to go one step further and add a possibility to
specify the sequence
of the expected field, when generating the query. That will be useful
for the tests
even if there's no UI for it yet.
On a related note, because the fields have changed order, this also
changes the order in which query constraints appear on the query page.
Same remark as above.
I'm thinking about a Query.get_column_order(), that would for now return
a sequence of the fields (starting with 'id', ending with 'reporter'
'keywords', 'cc').
The get_cols() fields will then be reorganized to match the sequence above.
Later, if/when we have an UI, the get_column_order() would give back the
user
defined order.
----
Not strictly related to the above, there's also the issue of the
'Status' field in the query:
if one adds new statuses in the config, they don't show up in the list,
because
there, the available statuses are still read from the db (enum table).
So there are two possibilities: either read the statuses from the .ini,
if possible,
or extend the trac-admin with a command to manipulate status (as I did for
the resolutions in r2846).
Using the first solution, the status are not sorted:
Status |_| resolved |_| assigned |_| verified |_| closed |_| new |_|
reopened
Using the second one, well, this is a bit inconvenient as there would be
the need to configure the workflow at two different places.
-- Christian
Patch for the first solution:
Index: trac/ticket/model.py
===================================================================
--- trac/ticket/model.py (revision 2845)
+++ trac/ticket/model.py (working copy)
@@ -402,7 +402,20 @@
class Status(AbstractEnum):
type = 'status'
+ def select(cls, env, db=None):
+ if 'ticket-status' in env.config:
+ statuses = []
+ for name, _ in env.config.options('ticket-status'):
+ s = Status(env)
+ s.name = s._old_name = name
+ s.value = s._old_value = len(statuses)
+ statuses.append(s)
+ return statuses
+ else:
+ return AbstractEnum.select(env, db)
+ select = classmethod(select)
+
class Resolution(AbstractEnum):
type = 'resolution'
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
