CoolCMS API

NotificationTargetDetachSubscriber
in package
implements EventSubscriber

FinalYes

Detaches admin notifications from a record the moment the ORM deletes it — the notification is not deleted, only its target column `id` is set to NULL, so the bell and the list show it as plain text instead of a link ending in 404.

Generic for every module: which entity a notification type points to is already declared by the module probes (NotificationTargetProbeInterface::typeKeysForEntity()), so a new notification type only needs its probe entry — no afterDelete hook per Api manager (those are opt-in and bulk deleteAll() / tree deleteNode() skip them; the UnitOfWork does not).

Two steps, because the ORM nulls the generated id of a removed entity before postRemove:

  • onFlush — collects type key => ids of entities scheduled for deletion (id still set),
  • postFlush — after the DELETEs ran, detaches the notifications with one raw UPDATE per type (no ORM flush inside a flush). Inside a caller's transaction the UPDATE shares it, so a rollback of the delete rolls the detach back too; a failed flush never reaches postFlush and the next onFlush starts from scratch.

Deletes outside the ORM (raw SQL, DB ON DELETE CASCADE) are caught by the daily NotificationOrphanCleaner. Fail-open: a failed detach is logged, the delete stays.

Registered automatically: Nettrine hooks every EventSubscriber service into the ORM event manager and instantiates it lazily on the first dispatched event.

Table of Contents

Interfaces

EventSubscriber

Properties

$notificationManager  : NotificationManager
$pending  : array<string, array<int, int>>
$probes  : array<string|int, mixed>
$typeKeysByClass  : array<class-string, array<int, string>>

Methods

__construct()  : mixed
getSubscribedEvents()  : array<string|int, mixed>
onFlush()  : void
postFlush()  : void
typeKeysFor()  : array<int, string>

Properties

Methods

On this page

Search results