[EMAIL PROTECTED] kirjoitti:
> Hello,
>> I see following solutions to this:
>>   * Don't allow type change
>>
>>   * Require default state for each ticket type and set that in
>>     case of change
>>
>>   
> 
> In another post I suggested to support ticket domains. Esp. in your case 
> (and some of my cases also) the "requirements" and the 
> "bug/enhancement/whatever" tickets have nothing in common, except 
> probably the name "ticket". The don't share a common workflow, they 
> don't have the same fields, in short they don't have anything in common 
> on the user interface side, but they have the same implementation logic 
> attached to it. If my opinion creating an enhancement from a requirement 
> is also an additional step in the workflow and should be treated in 
> exakt this way: create a new ticket in another domain (If you want you 
> could think of subtickets to retain the numbering). Ticket domains will 
> let users create any possible domain they need and you can attach any 
> workflow to it. They are kept in different tables in the database and it 
> should be easy to cross reference between different ticket domains. They 
> also can have a different layout,
> 
> The currently used type is simply a field for the "issue ticket domain". 
> The current usage of this field is over stressed to support different 
> unrelated ticket domains.
> 
> And the net benefit is: all new ticket domains (e.g. requirements 
> management, test amangement, and so on) can be implemented as a plugin ;-)

This sounds pretty much like Redmine approach. It has kind of a domains 
for issues which all can have (though from "common set") fields.

Also this sounds something very usable since it would still allow 
anybody to use current approach without interveting anything, but also 
allows more advanced usage.

Good thing that someone even thinks about this. Maybe this should be 
formalized a bit more since this sounds very good suggestion. It would 
abstract ticket system a bit more than it is now.

This might even resolve highly needed master/child/slave problem...

-- 
Jani Tiainen

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "Trac 
Development" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at 
http://groups.google.com/group/trac-dev?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to