>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 <andrej@digiverse.si> 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
>
|