bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Gary Martin <gary.mar...@wandisco.com>
Subject Re: BEP-0006 Ticket Relations, requirements clarifications
Date Tue, 07 May 2013 12:33:12 GMT
Hi,

I think that a relationship change event should be displayed in the 
ticket history on all tickets but there is definitely only one event. 
Storing two or more events where one would do seems a little strange. 
Perhaps maintaining the relation change history in a separate relation 
change table might be a bit better. After all, we don't have to restrict 
ourselves to getting the ticket history from the ticket_change table.

As for notifications, we don't want to flood a user with emails with 
every change. At worst we want one email per relationship change. Even 
better might be to group multiple changes: imagine a set of 
blocks/blocked-by type relationships where there is one ticket blocking 
many. When that blocking ticket is closed, we might expect all the 
related tickets to unblock at that point which is an effective bulk 
relationship change. There may be other ways to consider this though.

The BhRelationChanged interface makes good sense to me, along with the 
addons for notifications systems and search.

Cheers,
Gary

On 06/05/13 14:54, Peter Koželj wrote:
>  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
>>

Mime
View raw message