>From user's perspective A depends on B and B block's A are one and the same relation and should only produce a single notification and history log.
Each relation should be owned by one one of the tickets and when that relation is changed (added/removed) that ticket should be considered as changed also. For the case od depends-on this should be the ticket that depends on another ticket. For parent-child this should probably be the parent. We need to do a similar decision for all supported relation types. Peter On 6 May 2013 15:39, Andrej Golcov <[email protected]> wrote: > Hi all, > > Bhrelations API is more or less stabile now. It is possible to create > and delete relations with optional cycle validation. There is also > possibility to reject ticket resolution if there are open children > tickets. > > While bhrelations is designed to provide relations for different > resource types, ticket relations require more deep integration. > > I would like to discuss how creation or deletion of ticket relation > should be reflected in tickets, notifications and history. > > For example, user established a new "depends on" relation between two > tickets - in bhrelations that means two relations: #t1 depends on #t2 > and #t2 dependent from #t1 . Does it mean that both tickets were > modified? Should we generate two "ticket changed" mails? > > Personally, I don't think that tickets should be modified on a > bhrelation modification. I would suggest the following integration > between tickets and bhrelations on relation creation or deletion: > - insert records into the ticket_change table for both tickets to > obtain history > - introduce a new "BhRelationChanged" interface to enable "relation > changed" mail notifications. As part of the solution: we can provide > our own events and add-on for AnnouncerPlugin and TracNotification > - add add-on for bhsearch to enable search through tickets by relations > > Thoughts, suggestions? > > Cheers, Andrej >
