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]
