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