Add possibility to implement new Ticketstatuses

[benjaminmeissner]

Currently its not possible to implement new statuses due to the fact that the statuses array is hardcoded in TicketMessageInterface. It is not possible to override this constant in an extended Interface of TicketMessageInterface, because Interfaces are not allowed to do so.

I do need to introduce some extra statuses in one of my projects and will be happy to contribute my work.

My approach would be:
Remove STATUSES Array from TicketMessageInterface and require implementing classes to implement a static method getStatuses wich will be implemented in TicketMessageTrait and is returning literally the same array for basic functionality (and backwards compatibility). Extending classes of TicketMessage could override this function to achieve the goal of introducing new Statuses. Then the whole bundle will be refactored to use this new method instead of the static array.

Another approach could be to implement ticket statuses as an own entity. This would enable the Ticket admin to define new statuses via Backend. This requires some serious consideration towards backwards compatibility though:

• How can you add the current statuses to this new entity without needing to have an extra field for the old status id or a resolver mapping those?
• What will be the logic to propagate default Statuses anyway?
• How can you handle translations of the new statuses from backend in a multi language setup?
• Is it worth the effort or should it just be considered for a new version with some kind of general redesign?

I already forked the Repository into my organisation und will probably implement my approach (or a similar one, I'm open to that). Obviously I can just use my fork for my project but is this change likely to be accepted?

cheers

[benjaminmeissner]

I kinda finished the rework for my project.

getStatusString() and setStatusString() of TicketMessageInterface gave me kind of a hard time because it was hard finding a way to get the right array in my aproach without depending on a Helper function inside an Entity. I figured out, that the only usage of these functions seems to be in Twig Templates. So i introduced a twig function handling the Mapping of Status IDs to Status strings.

Did i miss something about these functions?

I will put some further time in Testing, fixing tests and adding documentation. Maybe ill be able to finish today but i think next week is more likely.