Thank you for the amazing response to the JTicketing 2.1.0 release. We are happy to bring you the roadmap for the changes planned in the next major release - JTicketing 2.2.0. The main focus of this release is the event waiting list that will allow people to enrol for the event even after the maximum number of registrations has been reached. Read on for the detailed list of features planned for the next major release.
For an event that has already reached its maximum number of attendees, an Event Waiting List will allow people to enrol for the event even after the maximum number of registrations has been reached. This will allow you to track information about other people who are willing to attend the event and process their booking for the event. If auto enrol feature is enabled from the backend, those users who have access to self-enrol will get auto-enrolled for the event as soon as the seats are available and those users that have buy access will get an email when seats are available for booking the ticket.
At present, only one payment gateway can be configured in TJ Vendor for JTicketing. From JTicketing 2.2.0 onwards, multiple payment gateways can be configured for vendors in JTicketing thus adding more flexibility for the vendors.
If you use JTicketing with EasySocial events, then this feature is for you. With this, EasySocial event attendee count is updated for attendees attending the Easysocial events. Once an attendee buys a ticket for the EasySocial event, then attendee count for the EasySocial event is updated for integration of JTicketing with EasySocial.
Want to provide an “early bird” facility for your event? Similar to flight tickets, site admin can decide the date range for “early bird” in which tickets up to a specific date range will be cheaper and after that, the tickets would be priced normally or they will be more expensive than the normal price. We have introduced another level of booking for event tickets. Every event ticket type will have a start date and end date for restricting the ticket booking validity.
This feature allows you to set a per-user restriction on how many tickets they can buy. Earlier it was only possible to restrict this on a per transaction level. Now you can have an overall limit.
Order status changes now have a defined workflow where now order statuses can only be changed in a logical order. For instance, a pending order would only get confirmed or cancelled. A completed order won’t go in pending state.