The example of custom post statuses of bug, enhancement and Security issue seems like an odd choice to me.
For a CPT of ticket, it's generally not going to change what it's type is (i.e. bug, enhancement, question, task, security issue) over the course of it's lifetime, once it is properly classified. This seems more like a ticket_type taxonomy.
A better related example may be to consider what a ticket status would be as it progresses: Under Investigation, Accepted, Resolved, Closed, Wontfix, On Hold, Invalid, Duplicate, Feedback required, Review-ready etc. These would fit in better with what I'd guess most people think of as a status (changes over time), instead of a form of classification like the type would be.
Note, that this isn't a criticism of the code itself, just the example in the readme.
The example of custom post statuses of
bug
,enhancement
andSecurity issue
seems like an odd choice to me.For a CPT of
ticket
, it's generally not going to change what it's type is (i.e. bug, enhancement, question, task, security issue) over the course of it's lifetime, once it is properly classified. This seems more like aticket_type
taxonomy.A better related example may be to consider what a ticket status would be as it progresses:
Under Investigation
,Accepted
,Resolved
,Closed
,Wontfix
,On Hold
,Invalid
,Duplicate
,Feedback required
,Review-ready
etc. These would fit in better with what I'd guess most people think of as a status (changes over time), instead of a form of classification like the type would be.Note, that this isn't a criticism of the code itself, just the example in the readme.