The way we've worked doing this is to create substages to our milestones. It's kind of a pain in the arse sometimes, but moving the ticket from one stage to another gives us a nice sort. Tickets are closed after customer acceptance - or in some cases - the project is simply deactivated with the tickets residing in the milestone stage indefinitely.

Something like this:

S1V3 Beta Rollout
S1V3 Beta Remedied
S1V3 Beta Verified Fixed

It doesn't work for everyone, and we're still testing it - but at this point it's the only workaround we could come up with (aside from category assignment which doesn't provide an organized single view).

We don't always have the ticket initiator verifying, particularly when the customer submits a ticket. The staging is really necessary for our process / operation - otherwise the visibility simply isn't there - if it's not visible it'll pop up later.

The idea is useful, and I've been thinking about it.

There are, alas, situations where it is not fully appropriate.

For instance, we had a series open tickets with a local phone company recently: they failed to a "1" for dialing on a call forward, so we had them create a ticket... which gets assigned to someone... who promptly looks at the ticket, looks in the system, sends a message that "the customer should add a 1," and closes the ticket. (We didn't have access to the actual system). This game went on for nearly two weeks.

More practically, a scenario goes like this: a construction manager has a series of workers, such as a window framer. He wants to assign things like "frame windows in left section of third floor" to the framers. He darn well knows, however, that the framers won't do their job right-- they'll cut corners to get on to the next job and more revenue-- if he doesn't inspect their work.

So what he'd like is a system where they mark off their work as done, and then he checks off final approval as the "ticket orginator." (And in fact he'd like to schedule this fairly precisely, because he wants to be sure to do the review before the framing crew leaves, else he has to pay to bring them back... another matter).

Our typical situations are both somewhat similar and somewhat more complex... but since the person market "responsible" is the person who actually has to "do it," and that person is not always the person who can judge whether "it's really been done" and often _shouldn't or can't be_, restricting closure to the 'responsible' party is only effective in some situations.

+1 for me too. Perhaps you can't create the sophistications of Jira's workflow, but some elements of it would be great.

* permissions per user per task type per status

That is, some users can move a task from evaluate to 'in progress' and another to 'testing'. But another is able to then close it. Tasks need a type, because different task types will have a different set of statuses. Support tasks may not have testing. Development tasks will have testing, ported, etc. Sales tasks will be completely different again.