Differential D1000 Diff 2479 src/app/Observers/DomainObserver.php

Changeset View

Standalone View

src/app/Observers/DomainObserver.php

<?php		<?php

namespace App\Observers;		namespace App\Observers;

use App\Domain;		use App\Domain;
		use Illuminate\Support\Facades\DB;

class DomainObserver		class DomainObserver
{		{
/**		/**
* Handle the domain "created" event.		* Handle the domain "created" event.
*		*
* @param \App\Domain $domain The domain.		* @param \App\Domain $domain The domain.
*		*
Show All 20 Lines	class DomainObserver
* @return void		* @return void
*/		*/
public function created(Domain $domain)		public function created(Domain $domain)
{		{
// Create domain record in LDAP, then check if it exists in DNS		// Create domain record in LDAP, then check if it exists in DNS
\App\Jobs\DomainCreate::dispatch($domain);		\App\Jobs\DomainCreate::dispatch($domain);
}		}

		/**
		* Handle the domain "deleting" event.
		*
		* @param \App\Domain $domain The domain.
		*
		* @return void
		*/
public function deleting(Domain $domain)		public function deleting(Domain $domain)
{		{
//		// FIXME: This is pretty much redundant with "deleted_at" property

		$domain->status \|= Domain::STATUS_DELETED;
		vanmeeuwenUnsubmitted Not Done Inline Actions Shouldn't this be a progression on the dispatched deletion process having completed? vanmeeuwen: Shouldn't this be a progression on the dispatched deletion process having completed?
		machniakAuthorUnsubmitted Done Inline Actions It could, indeed. Then we should change `isDeleted()` so it also returns true when `!empty($this->deleted_at)`, or not? I don't want to make things more complicated at the moment. machniak: It could, indeed. Then we should change `isDeleted()` so it also returns true when `!empty…
		vanmeeuwenUnsubmitted Not Done Inline Actions The question is then how the complete process of deleting a domain (or a user for that matter) is reflected in real life, vs. the database record. I believe I intended for the database to reflect in 'deleted_at' the semantics for UI/UX -- including billing and pro rata temporis if you will, and for STATUS_DELETED to be the final confirmation. In a sense, deleting could spawn the dispatched process -- it creates a series of actions to need to have occurred much like creating a user does (ldap ready, imap ready). I think it is there where I figured STATUS_DELETED would add value compared to just deleted_at. vanmeeuwen: The question is then how the complete process of deleting a domain (or a user for that matter)…
		// Looks like it's not enough, we have to do a direct query
		// we don't want to invoke "updating" event here
		DB::table('domains')->where('id', $domain->id)->update(['status' => $domain->status]);
		vanmeeuwenUnsubmitted Not Done Inline Actions How about `$domain->save()`? vanmeeuwen: How about `$domain->save()`?
		machniakAuthorUnsubmitted Done Inline Actions `save()` would work, but would generate `updated`/`updating` event which we don't need/want. machniak: `save()` would work, but would generate `updated`/`updating` event which we don't need/want.
		vanmeeuwenUnsubmitted Not Done Inline Actions I think we need to settle what `deleting` and `deleted` is compared to `deleted_at` vs. `STATUS_DELETED`, before we need to consider `$domain->save()` and its triggering of `updating()`/`updated()`. vanmeeuwen: I think we need to settle what `deleting` and `deleted` is compared to `deleted_at` vs.

		// Entitlements do not have referential integrity on the entitled object, so this is our
		// way of doing an onDelete('cascade') without the foreign key.
		\App\Entitlement::where('entitleable_id', $domain->id)
		->where('entitleable_type', Domain::class)
		->delete();
}		}

/**		/**
* Handle the domain "updated" event.		* Handle the domain "deleted" event.
*		*
* @param \App\Domain $domain The domain.		* @param \App\Domain $domain The domain.
*		*
* @return void		* @return void
*/		*/
public function updated(Domain $domain)		public function deleted(Domain $domain)
{		{
//		\App\Jobs\DomainDelete::dispatch($domain);
}		}

/**		/**
* Handle the domain "deleted" event.		* Handle the domain "updated" event.
*		*
* @param \App\Domain $domain The domain.		* @param \App\Domain $domain The domain.
*		*
* @return void		* @return void
*/		*/
public function deleted(Domain $domain)		public function updated(Domain $domain)
{		{
\App\Jobs\DomainDelete::dispatch($domain);		//
}		}


/**		/**
* Handle the domain "restored" event.		* Handle the domain "restored" event.
*		*
* @param \App\Domain $domain The domain.		* @param \App\Domain $domain The domain.
*		*
* @return void		* @return void
*/		*/
public function restored(Domain $domain)		public function restored(Domain $domain)
Show All 16 Lines