As part of the implementation of #96, we need the ability to generate art tickets that don't involve multiple parents but should still render in the getTicket,showTicket, and getDetailedTicket interfaces. This will certainly require substantial modification to the underlying code for ticket tracking?
Suggested Plan
Add a 'ticket_type' field to DB to distinguish breeding and modification tickets
Add an 'ticket_item_consumed' field to DB to indicate what item generated the ticket
add a code switch for getTicket and getDetailedTicket to render different details based on the type of ticket
Modification tickets will likely only display the create date, requesting user, item consumed, and a ticket comment string that indicates the requested modification (for future-proofing I'll leave open taking it in as an arg)
Ticket Statuses may have to be updated to reflect changes to the nature of tickets (for example Breeding in Progress becomes Ticket in Progress
As part of the implementation of #96, we need the ability to generate art tickets that don't involve multiple parents but should still render in the getTicket,showTicket, and getDetailedTicket interfaces. This will certainly require substantial modification to the underlying code for ticket tracking?
Suggested Plan