| | 1 | = Generalized Ticket Links |
| | 2 | |
| | 3 | This proposals corresponds to the implementation of #31 and the related tickets, like #886/#9550. |
| | 4 | |
| | 5 | The work started on this topic by bootstrapped by the [repos:66f599dd26c8/ticket-links patch] contributed by Joachim Hoessler on that ticket. |
| | 6 | |
| | 7 | The approach from this patch was preferred over the ones from existing plugins (TH:MasterTicketsPlugin, TH:SubticketsPlugin, TH:ChildTicketsPlugin) as none was providing a really extensible starting point, in the spirit of #31. The first two use a specific table dedicated to the relation they're dealing with (respectively `mastertickets(source, dest)`, `subtickets(parent,child)`), and the latter is using a `parent` custom field. That is not to say there are no interesting ideas to lift from there ;-) |
| | 8 | |
| | 9 | The initial data model `ticket_links(source, type, destination)` is quite close in spirit to the one proposed in TracRelations, but is focusing on the tickets. This is a good thing, as previous attempts at creating tables for storing relations between any resources are difficult to push through. Second, storing the relations while being centered on a particular resources are also in line with my recent updates to the GenericTrac proposal (see GenericTrac#Relations), so this approach can be seen as a practical test ground for those ideas. |
| | 10 | |
| | 11 | Besides this, there are no big plans yet for this feature - it'll eventually go to the point of implementing fully #31 and #886, but not up to the SubTickets proposal. |
| | 12 | |
| | 13 | The TicketLinks page describes the work in progress in the [repos:ticket-links] Mercurial branch. |
