bloodhound-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Andrej Golcov <and...@digiverse.si>
Subject Re: BEP-0006 Ticket Relations, requirements clarifications
Date Tue, 07 May 2013 16:02:16 GMT
[...]
> 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.
Yes, this is definitely an option. But having an additional source for
ticket history will bring more work and SQL selects on UI ticket page.
That can be also a problem for plugins that consume ticket_change data
for some needs e.g. search, statistic or something else.

> 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.
I think that if a user is subscribed on ticket change notification
(e.g. put mail in "cc" field) for at least one of two related tickets,
notification should be send to the user. So, in this case, the
relation changed notification is connected to ticket changed
notification. But we could incorporate this logic as part of our
"relation changed" notification logic.

BTW, what notification facility is used in i.a.o.? Should we
concentrate effort for relation notifications on AnnouncerPlugin or
build-in Trac Notifications?

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

Cheers, Andrej

Mime
View raw message