Hi,
I am preparing a prototype implementation of Ticket Relation
functionality. I started using trac-ticket-links branch as basis but
trying to encapsulate changes in the bhrelations plugin in order to
minimize difference with the vedor branch. The increased number of
Trac core patches forced me to step back and to open this discussion.
So far, I see the following possible ways of implementing ticket
relation data modification:
- trac-ticket-links way:
* changing of ticket relations data is part of a ticket
modification action (ticket.save_changes, insert, delete).
* ticket relation fields are special ticket fields - a lot of Trac
core patches should be introduced here.
* ticket-links fields are persisted only in special TicketLinks
table without adding any columns into Ticket tables.
Pros: is more robust design and less workarounds compared to master-ticket way.
Cons: Big number of changes have to be made in Trac core. Especially,
changes in trac.ticket.query module are hardly incapsulated as a
plugin. Support of custom queries introduces even more complications
and patches.
- master-tickets plugin way:
* changing of ticket relations is part of a ticket modification
action (ticket.save_changes, insert, delete)
* the plugin uses ticket custom fields (ticket ids in comma
separated representation) and also manage relation table during
ITicketChangeListener events
Pros: no major Trac core changes. Custom query is supported out of the
box based on ticket custom fields.
Cons: possible overlapping with other custom ticket fields. Adding or
renaming relation types leaves possibility to have strange artifacts.
UI logic have to be modified in order to treat ticket-relation custom
fields in special way.
- Implement ticket-relation as separate api not connected to ticket
fields and ticket changing action. As far as I understand, UI mockup
for BEP-0006 [1] assumes that ticket relations are manages on separate
page.
Pros: the implementation will be much more clear without big Trac patches
Cons: Duplicate workflow assumes the duplicate ticket Id as part of
the ticket changing - because ticket model does not know about ticket
relations some black magic should be implemented here - any ideas are
welcome. It is hard to add ticket relations to custom queries, but
bhsearch can support ticket relations easily.
Personally, I prefer the third way - no dependency on ticket model,
ticket relations have their own API and modification UI. However there
is still an open question for me: how to implement Duplicate workflow
properly.
Any thoughts, suggestions?
[1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006
Cheers, Andrej
