Edgewall Software

Changes between Initial Version and Version 1 of TracDev/Proposals/TicketLinks


Ignore:
Timestamp:
Aug 6, 2010, 10:50:21 PM (11 years ago)
Author:
Christian Boos
Comment:

overview of the ticket-links approach for implementing #31

Legend:

Unmodified
Added
Removed
Modified
  • TracDev/Proposals/TicketLinks

    v1 v1  
     1= Generalized Ticket Links
     2
     3This proposals corresponds to the implementation of #31 and the related tickets, like #886/#9550.
     4
     5The work started on this topic by bootstrapped by the [repos:66f599dd26c8/ticket-links patch] contributed by Joachim Hoessler on that ticket.
     6
     7The 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
     9The 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
     11Besides 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
     13The TicketLinks page describes the work in progress in the [repos:ticket-links] Mercurial branch.