Added Classes for display elements, Classes for Tickets, two new hook…

[thebeline]

…s and Check-In in full ability.

This PR has my classes from previously (I will close that PR), as well as added Classes to Tickets (for use on front-end and/or filtering/validation), two new filters for validating can_checkin and validating requested tickets in process_ticket_selections. It also adds a new feature allowing tickets to Check-In in Full (checking in or out on any ticket DateTime will result in syncing all related DateTimes to the same status) enabling single check-in for events where the Ticket allows earlier access, but the ticket is exchanged for some other identification once in.

Also, all related Admin interfaces, and template parts are added/updated as well.

I am not sure where to put this, but the related SQL is:

ALTER TABLE `wp_esp_ticket`
	ADD COLUMN `TKT_class` VARCHAR(245) NOT NULL DEFAULT '' AFTER `TKT_description`;
ALTER TABLE `wp_esp_ticket`
	ADD COLUMN `TKT_full_checkin` TINYINT(1) UNSIGNED NOT NULL DEFAULT '0' AFTER `TKT_taxable`;

The related code allows for some awesome things, for instance, I am able to require Adult Tickets be purchased when purchasing a Teen Ticket with:

function require_adult($true, $order) {
	
	$DTT_IDs = array(
		'provides' => array(),
		'requires' => array()
	);
	foreach ($order['ticket_obj'] as $TKT_ID => $ticket)
		if ( ! empty($order['qty'][$TKT_ID]) )
			if( preg_match_all('/(?<=^| )(requires|provides)_adult(?= |$)/', $ticket->get('TKT_class'), $matches) )
				foreach($ticket->datetimes() as $DTT)
					foreach($matches[1] as $give_take)
						$DTT_IDs[$give_take][$DTT->ID()][] = $ticket->name();
	
	$un_satisfied = array();
	foreach ($DTT_IDs['requires'] as $DTT_ID => $tickets)
		if (!isset($DTT_IDs['provides'][$DTT_ID]))
			$un_satisfied += $tickets;
	
	if (!empty($un_satisfied)) {
		$un_satisfied = array_flip(array_flip($un_satisfied));
		$tickets = 'ticket'.(count($un_satisfied) > 1 ? 's' : '');
		$last = array_pop($un_satisfied);
		$ticket_string = implode(' and ', array_filter(array(implode(', ', $un_satisfied), $last)));
		EE_Error::add_error(
			sprintf(
				__( 'The %1$s %2$s can not be purchased without an Adult ticket', 'event_espresso'),
				$tickets,
				$ticket_string
			),
			__FILE__, __FUNCTION__, __LINE__
		);
		return false;
	}

	return $true;

}

Which I think is pretty powerful...

Also, using classes, I was able to create tiers of tickets and display special notices about each, which you can see if you look at my event page: http://events.thomaspointbeach.com/events/thomas-point-beach-bluegrass-festival/

[thebeline]

Resolves #182 and #183

[thebeline]

Anything I can do to help that test pass? Travis CI is flipping out right now... :-/

[nerrad]

It's "flipping out" because of the changes in your pull request (namely the additions to the Ticket model).

Just a heads up that there's a lot of changes in this pull request. It's very unlikely there will be any quick action on this being that we're in the holiday season. Also our team will have to review this against other things we have on our roadmap to ensure there are no conflicts.

It's possible there will be some additional questions asked about these changes by various team-members as well.

[thebeline]

Awesome, I am very open to explaining things. And yes, I noticed it is due to the DB changes, which is why I asked if there was anything I can do to make Travis CI know about the changes. I see the migration scripts. I guess I assumed the DB was set up by the Model definitions. I did not see any Schema definitions in the codebase, but I could check again.

Yeah, I know it is a lot, my apologies. I could see about breaking them all into separate PRs, just where the two Ticket options would both create the "Advanced Ticket Options" tab, I am not sure how I would go about doing that.

I could, however, break the other things out, I guess... :-/

[mnelson4]

First off, we're all pretty impressed at how well you've grasped the EE code base.

Generally, it seems what you're trying to achieve would be more appropriate as an add-on, than changes to core. At very least first creating an add-on would be good, and then if it gains much traction (ie, other EE users use it or request the functionality) we could more seriously look into integrating it into EE core.

@tn3rb will have to comment on the aspects of SPCO, but from my part, @thebeline, the database change you're proposing (adding TKT_full_checkin) isn't how we'd like to achieve that functionality. It looks like a database change affecting ALL EE4 users, but would really only be useful for those who want the specific functionality this adds (the ability to check a registration into ALL datetimes simultaneously).
It would be more appropriate to use the EEM_Extra_Meta model for storing that info. When you have an EE_Ticket object, you can use $ticket->update_extra_meta() and $ticket->get_extra_meta (quite similar to WordPress' meta functions, except our "extra meta" can be used for storing arbitrary info onto any EE model objects).

Same thing with TKT_class. And that validation you're doing might be more appropriately done with an EE form (see https://github.com/eventespresso/event-espresso-core/blob/master/docs/J--EE4-Forms-System/ee-forms-system-overview.md for more info on that system); the model validation is now mostly used for just verifying data is valid according to MySQL before it's used there, not that the data is valid for our usage in PHP code or HTML.

Also, in order to achieve what you're wanting as an add-on, you may still need to open a pull request which adds a bunch of filters. Pull requests which only add filters are much more easily accepted.

[thebeline]

Closing this, please see #268. Cheers.