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. - Both properties can be set, unset and changed through manual editing. There are also links such as 'Add child ticket' on ticket pages. - 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. 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) 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. -- Dan Armak
pgpjkQA1lteVy.pgp
Description: PGP signature
_______________________________________________ Trac-dev mailing list [email protected] http://lists.edgewall.com/mailman/listinfo/trac-dev
