Chapter 10. Tracking state
This chapter covers
- Adding state to tickets and comments
- Using Active Record callbacks to trigger state changes
- Recording and displaying state transitions
- Securing specific model attributes elements against unauthorized modification
In a ticket-tracking application such as Ticketee, tickets aren’t there to provide information about specific problems or suggestions; rather, they’re there to provide the workflow for them.
The general workflow of a ticket starts when a user files the ticket; the ticket will be classified as a “New” ticket. When the developers of the project look at this ticket and decide to work on it, they’ll switch the state on the ticket to “open,” and once they’re done they’ll mark it as “resolved.” If a ticket needs more information, they’ll add another state, such as “needs more info.” A ticket could also be a duplicate of another ticket, or it could be something that the developers determine isn’t worth working on. In cases such as these, the ticket may be marked as “duplicate” or “invalid.”
The point is that tickets have a workflow, and that workflow revolves around state changes. In this chapter, you’ll allow the admin users to add states, but not to delete them. If an admin were to delete a state that was used, you’d have no record of that state ever existing. It’s best that states not be deleted once they’ve been created and used on a ticket.