Chapter 10. Tracking state
This chapter covers
- Adding a state-tracking ability to a model
- Using callbacks within Active Record
- Preventing basic form hacking
In a ticket-tracking application such as Ticketee, tickets aren’t there to provide information about a particular problem or suggestion; rather, they’re there to provide the workflow for it. The general workflow of a ticket is that a user will file it and it’ll 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, mark it as “resolved.” If a ticket needs more information on it then 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 worthwhile putting in. In cases such as this, the ticket may be marked as “duplicate” or “invalid,” respectively.
The point is that tickets have a workflow, and that workflow revolves around state changes. You’ll allow the admin users of this application to add states, but not to delete them. The reason for this is if an admin were to delete a state that was used, then you’d have no record of that state ever existing. It’s best if, once states are created and used on a ticket, they can’t be deleted.[1]