'Assign to' in 'new ticket' dialog

[Stephan]

Hi!

We are using Trac 0.11 on Windows 2K3.

Our goal is to be able to assign tickets already during creation.
There even is an 'assign to' field that can be filled out but when we
do so, the ticket still remains in 'new' status and is assigned to no
one.

What is this field meant for and how can we achieve (using a hook,
plug in, etc.) that a new ticket directly get's assigned to someone?

Regards,

Stephan

[Noah Kantrowitz]

New is a ticket state and has nothing to do with who owns the ticket. Please
read TracWorkflow for more information on customizing ticket workflows.

--Noah

[Stephan Stapel]

Hi Noah, Hi all,

> New is a ticket state and has nothing to do with who owns the ticket. Please
> read TracWorkflow for more information on customizing ticket workflows.

I have read the workflow chapter including the part on workflow
customization. Unfortunately I couldn't find information that helps me
in stepping automatically from 'new' to 'assigned' when the 'assigned
to' field is filled. Could you point me to the section you referred to
in your answer?

Regards,

Stephan

[Stephen Moretti]

2008/9/29 Stephan Stapel <stephan...@web.de>

From the work flow wiki page :

There are a couple of hard-coded constraints to the workflow. In particular, tickets are created with status new, and tickets are expected to have a closed state. Further, the default reports/queries treat any state other than closed as an open state. 

There is a way around this : http://trac-hacks.org/wiki/TicketCreationStatusPlugin

Regards

Stephen

[Jason Winnebeck]

This is interesting because what I have to do now is make the ticket (usually assigned to myself to keep from e-mailing other people), then reassign it to someone else, or in my custom workflow I have a state "unassigned," which is a signal for people to pick up new tasks in order of priority based on our current milestone (this is similar to agile sprints).

It sounds like I can use this plugin to start out immediately as unassigned or assigned? If I do that, does it go into unassigned state but with the default owner that Trac gives it (based on component)? Will this break the assumptions of Trac/timeline/plugins that assume that the first state for any ticket is "new" and key on that?

Jason

________________________________________
From: Stephen Moretti

[Stephen Moretti]

2008/9/30 Jason Winnebeck <jpw...@rit.edu>

This is interesting because what I have to do now is make the ticket (usually assigned to myself to keep from e-mailing other people), then reassign it to someone else, or in my custom workflow I have a state "unassigned," which is a signal for people to pick up new tasks in order of priority based on our current milestone (this is similar to agile sprints).

It sounds like I can use this plugin to start out immediately as unassigned or assigned? If I do that, does it go into unassigned state but with the default owner that Trac gives it (based on component)? Will this break the assumptions of Trac/timeline/plugins that assume that the first state for any ticket is "new" and key on that?

Putting a name/email address in the "assigned to" box gives the ticket an owner, so this plug in takes the owner state as being the start status, which would allow you to set the start state as being assigned.  This is exactly what I use it for.  I thought of forcing tickets into an accepted state, but 

For me new tickets go to a "new" status if they aren't given an owner.  Also, I don't use default owner setting, as new tickets should have no owner in our set up.  This means, I'm afraid, I have no idea if setting the default status to "unassigned" will pick up the default owner from the ticket ini settings.

Status is really just a text field used for reporting, so if you skip on by "new" you'll never see "new" tickets in the reports or associated with milestones. But then there are plug ins that allow you to mess with the milestones and you can create whatever custom queries you need for ticket reporting. You just need to make sure that your workflow is capable of handling this interruption to the flow of the tickets.  If you set the status to something that doesn't exist in your workflow, then you're ticket will most likely end up stuck in a "leave" loop and you'll have to hack the database to be able to fix the ticket.

Stephen

[Barbara Post]

Hello,

I found this interesting discussion about ticket workflow and initial
state, so I reply to it to keep sane google groups archives ;)

My following thought directs somewhat to Trac developpers.

I wonder whether http://trac-hacks.org/wiki/TicketCreationStatusPlugin
feature could be integrated into core Trac (I'm currently using Trac
0.11.4).

In my case this would lead to : person A creates a ticket and fills in
"assign to" to assign it to person B. So status would be updated
("assigned") as well as owner. I find this intuitive : the person who
creates a bug report has the right (in term of team management) to
assign it to some developper (for example in a small team), and then
could do it with only one save operation.

Do you think it is idiot ?

Barbara

On 30 sep 2008, 18:24, "Stephen Moretti" <stephen.more...@gmail.com>
wrote:
> 2008/9/30 Jason Winnebeck <jpw...@rit.edu>
>