On 07/05/13 17:02, Andrej Golcov wrote:
[...]
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.
Fair enough. Keeping it in ticket_change is consistent with batch
modification which makes it quite easy to justify. I don't know if it is
worth making any extra use of that fact for this.
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?
We are not using AnnouncerPlugin at the moment. We do have
TracWikiNotification installed which may have implications for any
change, aside from any possible issues with working with multiproduct
when we get there.
Cheers,
Gary
