Dynamic Ticket Types to Replace Hardcoded Values

[nolotz]

Currently, the ticket types are hardcoded within Ticket::TYPES. This approach, while straightforward, limits the system's flexibility and adaptability. In scenarios where different or additional ticket types are needed, the hardcoded list becomes a constraint.

I propose implementing a more dynamic system for managing ticket types. This could involve allowing ticket types to be defined and managed through the settings panel.

I would love to hear your thoughts on this proposal. Does this idea align with your vision for Bileto? Are there any specific considerations to keep in mind for implementing such a feature?

[marien-probesys]

Context: one of our goals with Bileto is to slowly align the application with the ITIL practices. I'm not an ITIL expert myself and sources on the Internet don't all agree on what the types of tickets are, but the most common ones I'm aware of are: incident, request, problem and change.

At Probesys (and our customers as well), we only use requests and incidents. So this is basically the reason why these two types are hardcoded. Also, our priorities are definitely on different subjects.

Could you explain your need so I can better understand what you're trying to do, and see if we can provide an alternative?