Hi, I've been investigating how to integrate our implementation of ticket relations into Trac's ticket workflow for handling duplicate tickets. I have a basic prototype working which functions as described in BEP-0006[1]: - When a ticket status is changed to "resolve as duplicate", an additional input box is shown and the user is expected (also required) to enter the ID of the original ticket. - Upon submit, the ticket is validated and if validation passes a new relation is added.
There are a couple of workflow-related scenarios that should be discussed prior to committing the code: 1. If a ticket marked as duplicate is later reopened, is it the correct approach to remove the duplicate relation? I'd say yes, if a duplicate relation can only be created when a ticket is resolved (see 2. below). 2. Should the user be able to add/remove duplicate relations in the "Manage relations" form? I'd vote for no here, as I don't see much purpose in doing that outside of the ticket workflow. 3. Handling of existing duplicates during upgrade - duplicate tickets in existing environments do not have any relation to the original ticket, they are just marked as duplicate. How should we handle upgrades of such environments? We could leave them as they are, we could try to be smart and mark them as duplicates of tickets referenced in the comments, or we could list the duplicates in the setup output and leave it up to the admin to decide what to do. I'm leaning towards the latter here, but then again large environments may have large quantities of duplicates. [1] https://issues.apache.org/bloodhound/wiki/Proposals/BEP-0006 Thanks, -- matevz
