On 20.06.2013 03:27, Gary Martin wrote: > On 19/06/13 23:24, Olemis Lang wrote: >> On 6/19/13, Anze Staric <[email protected]> wrote: >>> AFAIK, we only store duplicates as relations (no custom fields), so >>> multiple tickets could be selected. >>> >>> I agree with pre filling the field with ticket numbers extracted from >>> duplicated relations, but I do not see what purpose would selecting a >>> subset of them serve. The way I see it, input box is just a shortcut >>> to create duplicated relations. If we pre fill the field from existing >>> relations and user chose only a subset of them, what would be the >>> expected result? Should we delete the relations he did not select? If >>> we just ignore them, why offer the option to select them. >>> >> This makes sense to me. If it is a duplicate of many then why bother >> choosing a subset ? resolution = duplicated plus «duplicate» ticket >> relationships should be enough afaics . >> > > I think I agree with Anze and Olemis here. I'm not sure it helps to > pick out one or a subset of these relations that cause the ticket to > be worthy of closing at that point. It seems more likely that a ticket > is closed for duplicating all of them so I would probably only use > closing as a duplicate as an opportunity to add further duplicates if > they wish. Requiring that a duplicate ticket is noted if there has not > already been one added seems fairly reasonable. > > I've also taken a bit of time to consider the constraints on > duplicates that are listed in BEP-0006 as I want to check that they > make enough sense. I'm not convinced that either of them are required > but, as constraints are things that can be relaxed later, I'm not > interested in getting rid of them early unless they cause particular > issues. That said, I have two questions: > > 1. do we care that a ticket with a duplicate relationship might get > moved to a new product?
I don't think products should have any bearing on relationships. It's perfectly valid to create subtasks in different products, or mark duplicates in several products, for example. > 2. with the constraint that users can only set newer tickets as > duplicates of older tickets, will that just be confusing when the user > attempts it? Doesn't make sense. "Duplicate" is a symmetric relationship. And "resolve as duplicate" is valid workflow for any duplicate ticket, regardless of whether it's older or not. What /might/ be an interesting constraint is not allowing "resolve as duplicate" on all tickets in a duplicate set -- but that's an enhancement that could be added later. N.B.: duplicate set == transitive closure of all tickets reachable through duplicate relationships. -- Brane -- Branko Čibej | Director of Subversion WANdisco // Non-Stop Data e. [email protected]
