Hi,
Ticket must be registered to a Project (at least to limit visibility).
And ticket is likable to Product through the Original version (it's not linked to the product, but the version of the product). This also introduce a link to project as Projects are linked to Versions.

In fact, Ticket existed much before Product was introduced and Product management is optional, so link to Project must be kept to avoid complete refactoring.

I disagree with that - defects are related to the product and the version. If we are talking about project then it is very difficult to define the problem in many cases:
- defect is found in current development project: Ok
- defect found in released version - to what project it should be raised?

If ticket is handled, then there is at least a project to manage it.

On validation phase : in most cases it is linked to develpment Project, or maybe a project is devoted to validation

On production phase : a maintenance project must exist (otherwise no-one will ever open the ticket)

Some people working different way: maintenance project may not yet be creaated, so issues are stored awaiting to be picked up when project will be created. Some of the issues may not go to that project let's say for different reasons and will be deferred for a while. Do not forget- the content of the project need to be approved based on time scale, budget, business cases, etc., so issues cannot be assigned to the project automatically

At least you should have a dummy project to attach tickets.
I never saw any ticket management, whatever the tool, where tickets are registered and no project is open for this.
Tickets not linked to a project will never be handled : no-one will ever take care of them.

Moreover, there is a technical need to attach tickets to a project. List of values in the ticket (Responsible, Planning Actvity, ...) are restricted to the project data.
This is unavoidable when dealing with a large number of Data.
I are currently ruinning some heavy volume tests (1000 projects, 500 resources, 10000 tickets, 10000 activities), and without this restriction, sytem would fall down.

Regards.

Hi all,

we have solved it this way. We have a project called "Maintenance ". 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.