Feature: Handling Cases for User to Customer Relationships

This commit handles a case where customer data are "dead-data" menaing there is no way of erasure for them, which makes the app non-compliant

src/Privacy/Events/UserErasureRequested.php

@@ -0,0 +1,19 @@
+<?php
+
+namespace Modules\Core\Privacy\Events;
+
+use Modules\Core\Privacy\Models\DataErasureRequest;
+
+/**
+ * Fired by PrivacyService::requestErasureForUser() right after the grace-period
+ * request is created (not at completeErasure() time — see
+ * Modules\Core\Privacy\Listeners\CascadeCustomerErasureListener, which needs to
+ * act while the User is still linked to their Customers, before any detach has
+ * happened).
+ */
+class UserErasureRequested
+{
+    public function __construct(
+        public readonly DataErasureRequest $request,
+    ) {}
+}

src/Privacy/Listeners/CancelErasureOnLoginListener.php

@@ -2,6 +2,7 @@
 
 namespace Modules\Core\Privacy\Listeners;
 
+use Illuminate\Contracts\Queue\ShouldQueue;
 use Modules\Core\Auth\Events\UserAuthenticated;
 use Modules\Core\Privacy\ErasureRequestStatus;
 use Modules\Core\Privacy\Models\DataErasureRequest;
@@ -15,13 +16,27 @@ use Modules\Core\Privacy\PrivacyService;
  * happens to the account afterward: any pending request is cancelled and the
  * login block lifted (see PrivacyService::cancelErasure()).
  *
- * Only checks this User's own erasure request, not any Customer-scoped one — a
- * Customer-scoped erasure never deactivates a User's login at all (see
- * docs/privacy.md "User-scope vs Customer-scope"), so there is nothing for a
+ * Only checks this User's own erasure request, not any Customer-scoped one
+ * directly — a Customer-scoped erasure never deactivates a User's login at all
+ * (see docs/privacy.md "User-scope vs Customer-scope"), so there is nothing for a
  * login to reactivate on that side. Only a User-scoped request (keyed on this
  * User's own id) can have deactivated this login in the first place.
+ *
+ * If cancelling that request undoes it, this also reverts every Customer
+ * erasure request it caused (via Modules\Core\Privacy\Listeners\
+ * CascadeCustomerErasureListener — see DataErasureRequest::caused()). Those are
+ * traced by caused_by_request_id specifically so only the cascade THIS User's
+ * own request triggered is reverted, never an unrelated, independently-requested
+ * Customer erasure the User happens to be linked to.
+ *
+ * Queued (ShouldQueue) — login should return to the browser quickly, without
+ * waiting on this bookkeeping. Nothing else in this codebase currently reads
+ * deactivated_at except this listener and PrivacyService itself (grep before
+ * assuming otherwise, if that ever changes) — UserOtpService::validate() never
+ * gates the login on it — so a brief window between the login response and this
+ * job actually running has no other consumer to observe it as stale.
  */
-class CancelErasureOnLoginListener
+class CancelErasureOnLoginListener implements ShouldQueue
 {
     public function __construct(private readonly PrivacyService $privacyService) {}
 
@@ -33,8 +48,14 @@ class CancelErasureOnLoginListener
             ->latest()
             ->first();
 
-        if ($request) {
-            $this->privacyService->cancelErasure($request);
+        if (! $request) {
+            return;
+        }
+
+        $this->privacyService->cancelErasure($request);
+
+        foreach ($request->caused as $causedRequest) {
+            $this->privacyService->cancelErasure($causedRequest);
         }
     }
 }

src/Privacy/Listeners/CascadeCustomerErasureListener.php

@@ -0,0 +1,64 @@
+<?php
+
+namespace Modules\Core\Privacy\Listeners;
+
+use Illuminate\Contracts\Auth\Authenticatable;
+use Illuminate\Contracts\Queue\ShouldQueue;
+use Lunar\Base\LunarUser;
+use Lunar\Models\Customer;
+use Modules\Core\Privacy\Events\UserErasureRequested;
+use Modules\Core\Privacy\PrivacyService;
+
+/**
+ * When a User's erasure leaves a Customer account with no remaining User at all,
+ * that Customer's PII (name, addresses, order history) becomes permanently
+ * unreachable through any login — GDPR data minimization (Art. 5(1)(c)) means it
+ * shouldn't just sit there. This listener checks every Customer the User is
+ * linked to: if this User is currently the SOLE user on that Customer (count ===
+ * 1 and that one user is this user — not just count === 1, in case of a
+ * stale/unexpected read), it also opens a grace-period Customer erasure request
+ * for that Customer, tagged via caused_by_request_id so
+ * CancelErasureOnLoginListener can revert exactly this cascade — and only this
+ * cascade — if the User logs back in and changes their mind.
+ *
+ * Queued (ShouldQueue), not synchronous — this runs as an independent,
+ * separately-retryable unit of work rather than inline inside
+ * PrivacyService::requestErasureForUser(), so a failure here never rolls back or
+ * blocks the User's own request. Because Eloquent models on a queued event are
+ * re-fetched fresh when the job actually runs (not a stale snapshot from dispatch
+ * time — see Illuminate\Queue\SerializesModels), $event->request->subject and its
+ * ->customers reflect the real, current state at execution time. That matters
+ * specifically for the immediate-erasure path (requestImmediateErasureForUser()):
+ * this job may run before or after completeErasure() detaches the User's
+ * memberships — if the detach happens first, ->customers is simply empty by the
+ * time this runs and nothing cascades, which is an accepted, understood race for
+ * that rare staff-triggered path (see docs/privacy.md). The everyday grace-period
+ * path (requestErasureForUser()) has no such race, since nothing detaches the
+ * User's memberships until its own later, separate completeErasure() run.
+ *
+ * Both requests then run through their own independent grace periods.
+ */
+class CascadeCustomerErasureListener implements ShouldQueue
+{
+    public function __construct(private readonly PrivacyService $privacyService) {}
+
+    public function handle(UserErasureRequested $event): void
+    {
+        $user = $event->request->subject;
+
+        if (! $user) {
+            return;
+        }
+
+        foreach ($user->customers as $customer) {
+            if ($this->isSoleUser($customer, $user)) {
+                $this->privacyService->requestErasureForCustomer($customer, $user, causedByRequestId: $event->request->id);
+            }
+        }
+    }
+
+    private function isSoleUser(Customer $customer, Authenticatable&LunarUser $user): bool
+    {
+        return $customer->users->count() === 1 && $customer->users->first()->id === $user->id;
+    }
+}

src/Privacy/Models/DataErasureRequest.php

@@ -3,6 +3,8 @@
 namespace Modules\Core\Privacy\Models;
 
 use Illuminate\Database\Eloquent\Model;
+use Illuminate\Database\Eloquent\Relations\BelongsTo;
+use Illuminate\Database\Eloquent\Relations\HasMany;
 use Illuminate\Database\Eloquent\Relations\MorphTo;
 use Lunar\Models\Customer;
 use Modules\Core\Privacy\ErasureRequestStatus;
@@ -44,6 +46,25 @@ class DataErasureRequest extends Model
         return $this->morphTo(__FUNCTION__, 'requested_by_type', 'requested_by_id');
     }
 
+    /**
+     * The User erasure request that caused this one to be auto-created, if any —
+     * see Modules\Core\Privacy\Listeners\CascadeCustomerErasureListener.
+     */
+    public function causedBy(): BelongsTo
+    {
+        return $this->belongsTo(self::class, 'caused_by_request_id');
+    }
+
+    /**
+     * Every Customer erasure request THIS request caused (see causedBy()) —
+     * used by CancelErasureOnLoginListener to revert exactly the cascade this
+     * User's own cancellation should undo.
+     */
+    public function caused(): HasMany
+    {
+        return $this->hasMany(self::class, 'caused_by_request_id');
+    }
+
     public function isForCustomer(): bool
     {
         return $this->subject_type === (new Customer)->getMorphClass();

src/Privacy/PrivacyService.php

@@ -4,9 +4,11 @@ namespace Modules\Core\Privacy;
 
 use Illuminate\Contracts\Auth\Authenticatable;
 use Illuminate\Database\Eloquent\Model;
+use Illuminate\Support\Facades\Event;
 use Lunar\Base\LunarUser;
 use Lunar\Models\Customer;
 use Modules\Core\Auth\Models\Staff;
+use Modules\Core\Privacy\Events\UserErasureRequested;
 use Modules\Core\Privacy\Jobs\ExportDataSubjectJob;
 use Modules\Core\Privacy\Models\DataErasureRequest;
 use Modules\Core\Privacy\Models\DataExportRequest;
@@ -80,11 +82,21 @@ class PrivacyService
      * privacy:process-erasure-requests picks this up once scheduled_for has
      * passed, unless cancelErasure() is called first.
      *
-     * $requestedBy is either the Customer themselves (self-service deletion) or a
-     * Staff member acting on their behalf.
+     * $requestedBy is the Customer themselves (self-service deletion), a Staff
+     * member acting on their behalf, or a User — the User case is for
+     * Modules\Core\Privacy\Listeners\CascadeCustomerErasureListener, where erasing
+     * a User leaves a Customer with no remaining user: the User is a real,
+     * meaningful "who caused this," even though they didn't directly request the
+     * Customer's own erasure. $causedByRequestId links a cascade-created request
+     * back to the User erasure request that triggered it, so
+     * CancelErasureOnLoginListener can revert exactly that cascade on login,
+     * without touching an unrelated, independently-requested Customer erasure.
      */
-    public function requestErasureForCustomer(Customer $customer, Customer|Staff $requestedBy): DataErasureRequest
-    {
+    public function requestErasureForCustomer(
+        Customer $customer,
+        Customer|Staff|(Authenticatable&LunarUser) $requestedBy,
+        ?int $causedByRequestId = null,
+    ): DataErasureRequest {
         return DataErasureRequest::create([
             'subject_type' => $customer->getMorphClass(),
             'subject_id' => $customer->id,
@@ -93,6 +105,7 @@ class PrivacyService
             'requested_by_id' => $requestedBy->getKey(),
             'status' => ErasureRequestStatus::Pending,
             'scheduled_for' => now()->addDays(config('core.privacy.grace_period_days', 30)),
+            'caused_by_request_id' => $causedByRequestId,
         ]);
     }
 
@@ -117,6 +130,13 @@ class PrivacyService
 
         $this->setUserDeactivated($user->id, true);
 
+        // CascadeCustomerErasureListener implements ShouldQueue, so this just
+        // enqueues a job rather than running inline — no transaction wrapping
+        // needed here, since the cascade check happens as an independent,
+        // separately-retryable unit of work after this request is already
+        // committed, not as part of this same call.
+        Event::dispatch(new UserErasureRequested($request));
+
         return $request;
     }
 
@@ -148,6 +168,15 @@ class PrivacyService
     /**
      * Erases a User's data right now, bypassing the grace period entirely.
      * Staff-only by construction — see requestImmediateErasureForCustomer().
+     *
+     * Still fires UserErasureRequested — and deliberately BEFORE completeErasure()
+     * runs, not after — so Modules\Core\Privacy\Listeners\
+     * CascadeCustomerErasureListener sees the User still linked to their Customers
+     * (completeErasure() -> CustomerDataProvider::eraseForUser() is what detaches
+     * the pivot). The User's own erasure is immediate, but any Customer left
+     * orphaned by it still gets a normal grace-period erasure request, not an
+     * immediate one — an orphaned Customer isn't itself the subject of the
+     * original urgent request.
      */
     public function requestImmediateErasureForUser(Authenticatable&LunarUser $user, Staff $requestedBy): ErasureReport
     {
@@ -163,6 +192,16 @@ class PrivacyService
 
         $this->setUserDeactivated($user->id, true);
 
+        // Queued (see requestErasureForUser()) — the cascade job may run before
+        // or after completeErasure() below detaches the pivot. Either is fine:
+        // CascadeCustomerErasureListener re-reads $user->customers fresh when it
+        // runs, so it only cascades if this User is still linked at that point.
+        // If completeErasure() detaches first, the queued job simply finds no
+        // Customers left to check and no-ops — never a wrong cascade, at worst a
+        // missed one on a race that immediate (staff-triggered, rare) erasure
+        // doesn't need to guard against as tightly as the grace-period path.
+        Event::dispatch(new UserErasureRequested($request));
+
         return $this->completeErasure($request);
     }