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. Anze On Wed, Jun 19, 2013 at 9:15 PM, Branko Čibej <[email protected]> wrote: > On 19.06.2013 20:56, Matevž Bradač wrote: >> On 19. Jun, 2013, at 20:13, Gary Martin wrote: >> >>> On 19/06/13 09:54, Branko Čibej wrote: >>>> On 19.06.2013 10:05, Andrej Golcov wrote: >>>>>> Yes, that's the straightforward reasoning. Just notice that workflow >>>>>> actions not necessarily have to modify ticket status. The most common >>>>>> example is leave action. >>>>> I mean: deleting or adding relation does not change ticket at all, IOW >>>>> this is not supposed to be ticket.save_changes action. Currently, user >>>>> is required to have *_CHANGE permission on resource (e.g.) to change >>>>> its relation but this can be easily changed in future. I can imagine >>>>> the business requirement that user can make relation between tickets >>>>> that he/she doesn't have change permission. >>>> I'd suggest that adding a duplicate relation does not necessarily imply >>>> that one of the tickets involved should be "resolved as duplicate". It >>>> is a valid, although unusual, workflow to mark as duplicate (possibly of >>>> several other tickets), and yet leave the ticket state unchanged. >>>> >>>> So I propose that the duplicate relation itself should not be special; >>>> rather, the "resove as duplicate" action should take account of existing >>>> duplciate relations, possibly still allowing the user to create yet >>>> another such relation. >>>> >>>> -- Brane >>>> >>> That is twice I agree with Brane completely in relatively quick succession! >>> >>> I have no problem with users marking tickets as duplicating outside of the >>> resolving tickets as duplicate method. Under those circumstances, it would >>> not be good to remove the relationship automatically on reopening as we >>> couldn't second-guess the reason for the relationship being added. >>> >> Ok, I suppose that's the way to proceed then. Am I correct to assume that >> resolving the ticket as duplicate should still require the user to enter >> a duplicate ID, as mentioned in the BEP? The current (Trac) implementation >> of duplicates without references is a bit awkward in that regard. > > Yes, I think that would make sense. And if it finds existing duplicate > relations on the ticket, show them to the user and allow them to select > one, or none, or perhaps even all (although that last very much depends > on whether the ticket schema can handle it). > > -- Brane > > > -- > Branko Čibej | Director of Subversion > WANdisco // Non-Stop Data > e. [email protected]
