Ticket project field

Hi all,

we have solved it this way. We have a project called "Maintenance <product>". From my pov, it isn't important to have an extra field called Products.

Klaus

Ok, so when you moving forward with new project you selecting some tickets from the maintenance pool and moving into new project. Am I right?
Regards,
Evgueni

Our Ticket always linked to Maintenance "Project". Every Ticket will be assigned (and delivered)to a target release, and will not be input or request for a 'real' project - normally. If we have a bundle of minor issues/Ticket, which have to be solved generally, i.e. interface latency issues, then we open an Activity - origin is Ticket - which has be run through our approval workflow -- this because Tickets burning a different budget then Activities.

Your suggestion, to "move Ticket from maintenance to new project" will be done at our Activities. We select all change requests under a generic "CHANGE project" with status backlog. Once a month, we checking all backlog tasks and assigning if needed to a project - in your words, we moving from generic CHANGE project to new project.