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. > Cheers, > Gary
