Dan Armak wrote:
Hello,
I'm going to implement hierarchical ticket dependencies for my company's
internal Trac site. I'm asking you, the Trac devs, how you'd like this to be
implemented, to give my work a good chance of being merged into Trac.
----
What I need in terms of end-user functionality: simple ticket deps, as in
#2078. This doesn't need any functionality not yet in 0.9/trunk. A brief
description:
- A ticket has a single optional parent and zero or more children. The data is
stored in two new fields in the ticket DB table and on the ticket object.
Accordingly it can be a parameter to /query and so on.
IIUC, you only want parent/child relationships, no additional
"depends-on" relationships?
Then you should maybe reconsider the limitation of single parenting, as
I think it's
quite common that a ticket "blocks" several others.
- Both properties can be set, unset and changed through manual editing. There
are also links such as 'Add child ticket' on ticket pages.
Have also look at:
- http://projects.edgewall.com/trac/ticket/2193
- http://projects.edgewall.com/trac/wiki/SubTickets#CreatingSubtickets
- A ticket cannot be closed if it has open child tickets. Reassigning an open
ticket to a closed parent reopens the parent. These are the only ways in
which existing behavior is affected by the parent/child relationships, and
there are no additional constraints built in.
And (this isn't from #2087):
- Query results (ticket lists displayed by /query and by [query:...]) have a
parameter (a checkbox next to the existing ones such as Show Full
Description) that makes the display a tree instead of a flat list, with
collapsible branches.
----
I've found a lot of talk about this on the Trac wiki and tickets. Some
patches, too, but they're old (0.7/0.8) and labelled as a proof-of-concept to
begin with. There seem to be several approaches:
1. #2078: standalone implementation as described above.
2. #31, #1242, the TracCrossReferences branch: very generic framework and
stuff.
Speaking of xref, I'd still like to push this forward ... However I never did
an UI for the ticket dependencies.
My plan was to follow-up on what Alec did with the WorkFlow, and add a
relation field type.
I'm looking forward for the UI you will put up, and I'm willing to adopt
if for xref.
3. #886: making milestones a special kind of ticket, some core Trac
refactoring.
4. WorkFlow branch: allows all the necessary modifications to the ticket page
to be a plugin. (But the /query modification still needs to be done
to /query, so the rest can't be a plugin)
If the query page is modified to allow pluggable "alternate" formats,
you could simply
plug-in a "Hierarchical View" there. Your plugin would then receive the
list of tickets
found by the query (+ eventually the query parameters) and you can
choose to display
them the way you like.
I like (1), that is #2087, because it's a simple and focused approach. The
others are all way overkill for what I want to do, and besides I'd have to
track a branch other than trunk for months, whereas (1) can be done right now
with trunk and with 0.9.
But if you all agree that it should be done in one
of those 'overkill' ways, maybe you'll convince me. And if not, I'll write my
short-term implementation to be reasonably forward-compatible in terms of
data storage to what you propose.
I think you certainly can get away with a plugin approach, especially if
based on the WorkFlow branch.
Then later, if I manage to move the infrastructure for generic Trac
objects and for generic relations between
them in the trunk, you will certainly have a much easier (trivial?) task
in your plugin, at least for the data
storage part.
In summary, I think that a good UI is certainly the most challenging
part for the parent/child
relationship and I can only encourage you to start something in this
direction. If time permits,
I'd be enthusiastic to help in this area too. For the data storage part,
you'd better create your
own table for now (ticket_hierarchy) and write ad-hoc code; that part
can always be improved
upon later. For the global approach, I'd suggest you go for 4), which I
think is the most
future-proof approach.
Also, for a new development like that, you should forget about 0.9
compatibility,
as 0.10 is getting nearer and the WorkFlow branch will jump-start the
development of 0.11.
-- Christian
_______________________________________________
Trac-dev mailing list
[email protected]
http://lists.edgewall.com/mailman/listinfo/trac-dev
