Description
This is a discussion ground of several major issue with the current architecture of the project which makes it incredibly hard to make logical decisions about the project as their is no formal set of requirements/specifications. Ask these questions and flesh out a specification to be followed in the future by maintainers and contributors.
Current Problems
What to do with order on ticket modification/deletion? (LT)
All previous orders are corrupted now. Choices:
- Prevent changing and deleting tickets
- Store price at the time of order creation
What to do on discount code modification/deletion? (LT)
Same as above
Why are there event and ticket discount codes? (Immediate)
Simplify the design. Currently, discount code contains a foreign key to event and then there is a table which maps discount code to tickets. But right now only ticket discount codes are being considered. What is to be done? This needs to be simplified and abstracted as multiple implementations and logical variations exist
How is discount code counted? (Immediate)
- If a discount code quantity is 100, does buying 5
Ticket Ain a single order and applying discount code subtract 5 or 1? - Is the discount applied on all ticket A (likely)?
- What's the use of
min_quantityin discount code? - What happens when discount code usage is exceeded partially? Applied to some tickets or order is declined?
- What happens if ticket count of
Ticket Aexceeds max_quantity of discount code? Applied tomax_quantitytickets or order is declined?
How to count discount code holders if a ticket is deleted? (Immediate)
If a ticket is deleted after an order is associated with a discount code, how should discount code usage be counted? With deleted ticket or without?
Should we tell users discount code is expired, inactive, or just exhausted and invalid? (Immediate)
Current Choices:
- Exhausted
- Invalid (Used for expired, inactive, future validity and actual invalid)
- Inactive
- Expired
What to do on event deletion? (Currently Solved)
Don't let the user delete an event if there are any pending or completed order. Requires any changes?
What to do on user deletion? (Currently Solved)
Don't let the user delete itself if there are any pending or completed order. Requires any changes?
More to add and discuss in future:
- Behaviour of Access Codes
- Behaviour of system roles and user roles and event roles and what is panel. It is very confusing
- Custom Form expectations. How much control and what kind of customisations are required
Further things are to be discussed in meeting and a spec is to be documented. Before fixing and implementing any feature, an expected behaviour and requirements doc will be created so that it is clear for future contributors what to implement and what to expect from the system and the transfer of knowledge is not needed from a single expert person