ticket_state_id = 1 (new)

[p3isys]

Greetings:
I have seen several tickets that seem to be stuck in ticket_state_id = 1 (new), even when moved to another queue, locked for working, notes added.

I have been able to get them out only by directly changing the ticket_state_id to 4 (open). It doesn't seem to happen too often, yet in our fairly new implementation of OTRS I have seen this phenomenon on at least 4 tickets.

It seems to manifest primarily in tickets auto-created via an external email, and though I'm not sure, I think the steps go something like this:
1. Email sent to OTRS address.
2. Ticket created from email
3. Ticket moved from default queue to work queue
4. Customer ID applied to populate customer info.
5. Ticket assigned to tech as owner.

The specific order of 3, 4, 5 may not be correct; I and my techs might do these differently, but in some cases the ticket state seems to be stuck in "new" no matter what is done in the OTRS user interface, though I'm still looking into the issue to learn more.

I'm continuing to experiment and will report results. In the meantime, has anyone else in the community observed anything similar to this?
Kind regards,
Rob M.

[jojo]

State will only change if set by agent (like on composing answer)

[crythias]

Check this
Config Options: Ticket -> Core::Ticket

enable this:

Ticket::EventModulePost###1-ForceStateChangeOnLock:
Ticket event module to force a new ticket state after lock action. As key you have to define the current state and the next state as content after lock action.

Anything that locks the ticket will make the ticket change from "new" to "open" (by default).