Allow transfer of ticket from type to another

[shreyas-satish]

Users sometimes want to be able to attend a different event from what they originally they bought the ticket for. A similar case, from a customer support standpoint, is when a user wants to convert a combo ticket to single event ticket because they received a free ticket to one of the events. In such a case, an admin should be able to satisfy the request without requiring the user to make another transaction (if that's possible).

Here's how this can work:

1. The admin clicks on 'Transfer' for the ticket in question (say A) in the dashboard, and selects the new ticket that the user wants (say B).
2. The system checks the difference of A - B.
   1. If this difference is >=0, the system successfully adds the new ticket to the order, processes a refund (if applicable) and sends a notification of the transfer to the user.
   2. If A - B is < 0, the system rejects the request, and in this case, the admin informs the user that a transfer is not possible.

[shreyas-satish]

There's an additional caveat here. The foreign key (`item_id) for the line item in question cannot simply be updated with the new ticket; we'd be losing information. A copy of the line item should be stored in an archive, and the foreign key should then be updated.

Note: https://github.com/hasgeek/boxoffice/issues/105 also requires data versioning.

[shreyas-satish]

The foreign key for the line_item in question doesn't need to be updated. It can simply be cancelled (which is what is happening in reality) and a new line item can be added to the order.

[shreyas-satish]

After discussing this with our accountant and with @jace, it seems to be better to make a new order with a link to the original order instead of new line item in the same order. I propose the following workflow.

1. If it's a valid change (according to the terms described above), the line item in the original order should be cancelled. A new order should be created with the chosen ticket and with a parent_id reference pointing to the original order. The backref should refer the 'child' orders as 'revisions'.
2. The new order's payment, transactions and invoice should point to the parent order's entries. The new order should have a receipt page which details the original payment and the refund that was made.
3. Assignee information should be copied over.
4. Subsequent changes should follow a similar workflow: the ticket created in the revised order should be cancelled, and a new order should be created with the revised ticket details. The new order's parent should be the original order i.e the order for which the payment was made for.
5. The original order's receipt page and its page on the admin dashboard should show the 'revised' orders under the heading 'Order revisions'.

[shreyas-satish]

At what price should the new ticket be charged? Should it be charged at the current price?

@zainabbawa points out that the new ticket should be charged at the price that was listed during the placement of the original order.

[shreyas-satish]

After further discussion, it's been decided to provide the admin the choice between charging at either the current price or the originally listed price.

[akshaybhalotia]

This came up again during FifthEl 2018 for 2 reasons:

1. We had to cancel the networking ticket and give them the benefits of hardcore ticket, but there was no way for the ticket to be transferred - it was only through an internal understanding that networking ticket need not be honored. Similar situation will arise for JSFoo 2018.
2. Due to some last minute schedule changes, people wanted to exchange their day 1 tickets for day 2 and vice-versa.