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 <[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
