Customer deletion fails due to foreign key constraints and leaves orphaned Users

[VincentTeresa]

Context

I'm working on an e-commerce site using Lunar where users can register, make purchases, and manage their accounts. The platform needs to handle customer account deletion properly when requested by users or administrators.

What I'm Trying to Do

Delete customers from the admin panel (/admin/customers) either individually or through bulk actions, ensuring that all related data is properly cleaned up, including associated Users.

The Problem

When attempting to delete a Customer that has associated data (carts, orders, addresses), the deletion fails with foreign key constraint violations. Additionally, when deletion is forced through bulk actions, it only detaches the User relationship, leaving orphaned User records in the database that prevent email reuse for new registrations.

What I've Checked

• Reviewed the CustomerObserver implementation
• Analyzed database migrations and foreign key constraints
• Checked for cascade delete configurations
• Searched for existing issues related to customer deletion
• Verified this affects both individual and bulk delete actions

Steps to Reproduce

1. Register a new user in the frontend (creates both User and Customer)
2. Add products to cart as that user
3. Navigate to admin panel → Customers
4. Attempt to delete the customer using bulk action
5. Observe the foreign key constraint error
6. If deletion succeeds (empty cart), check Users table - the User remains orphaned

Current Result

SQLSTATE[23000]: Integrity constraint violation: 1451 Cannot delete or update a parent row:
a foreign key constraint fails (`database`.`lunar_carts`, CONSTRAINT `lunar_carts_customer_id_foreign`
FOREIGN KEY (`customer_id`) REFERENCES `lunar_customers` (`id`))

Expected Result

Customer deletion should:

1. Handle or cascade delete related records (carts, addresses, etc.)
2. Either delete or properly handle associated Users
3. Allow email addresses to be reused after account deletion

Technical Details

Affected File: packages/core/src/Observers/CustomerObserver.php

Current implementation:

public function deleting(CustomerContract $customer)
{
    $customer->customerGroups()->detach();
    $customer->discounts()->detach();
    $customer->users()->detach();  // Only detaches, doesn't delete
    // Missing: cart handling, address handling, user cleanup
}

Related Issues

• Missing individual delete action in CustomerResource pages
• No cascade delete in foreign key constraints
• No user lifecycle management

Proposed Solution

Enhanced CustomerObserver that properly handles all relationships:

public function deleting(CustomerContract $customer)
{
    // Handle carts and their lines
    $customer->carts()->each(function ($cart) {
        $cart->lines()->delete();
        $cart->delete();
    });

    // Handle addresses
    $customer->addresses()->delete();

    // Handle users (delete if no other customers)
    $customer->users()->each(function ($user) {
        if ($user->customers()->count() === 1) {
            $user->delete();
        }
    });

    // Existing detachments
    $customer->customerGroups()->detach();
    $customer->discounts()->detach();
    $customer->users()->detach();
}

Additionally, add delete action to CustomerResource pages:

// In EditCustomer.php and ViewCustomer.php
protected function getDefaultHeaderActions(): array
{
    return [
        Actions\DeleteAction::make()
            ->requiresConfirmation(),
    ];
}

Environment

• Lunar version: 1.0.0-rc.7
• Laravel Version: 11.47.0
• PHP Version: 8.4.15
• Database Driver & Version: MySQL 8.0

Why This Matters

This is a critical issue for any production e-commerce site because:

1. GDPR Compliance: Users have the right to deletion of their data
2. Data Integrity: Orphaned records accumulate over time
3. User Experience: Customers cannot re-register with the same email
4. Admin Operations: Basic customer management is broken

Additional Notes

• This issue is similar to Unable to delete a brand #2030 (brand deletion constraints)
• The pattern affects multiple entities in Lunar (brands, products, customers)
• A comprehensive solution for cascade deletion strategy would benefit the entire framework

I'm already working on implementing this solution and will submit a PR shortly once the approach is confirmed.

[glennjacobs]

Thanks for the write-up and incoming PR.

I would also suggest that for GDPR the approach is ideally to anonymise the data, rather than delete. Certainly, orders should not be deleted and are outside of the GDPR requirement AFAIK.

[VincentTeresa]

Thank you for the feedback! You're absolutely right about GDPR - anonymization is the proper approach rather than deletion.

I agree that orders should be preserved for business/legal requirements. Here's my proposed approach:

For Customer deletion, I think we should:

1. Preserve order data with legitimate basis:

• Keep billing address with name (legal obligation - invoicing/tax requirements)
• Keep shipping address with name (legitimate interest - delivery proof, dispute resolution)
• Anonymize customer email → "deleted-user@anonymous.local"
• Remove customer phone (not needed for delivery verification)

2. Delete personal customer data:

• Customer profiles, personal addresses, carts, preferences

3. Clean up user accounts:

• Remove user accounts to free up email addresses for re-registration

4. Convert to guest orders:

• Set customer_id and user_id to null, making them anonymous guest orders

GDPR justification:

• Art. 6.1.c (Legal obligation): Billing addresses for tax/accounting
• Art. 6.1.f (Legitimate interest): Shipping addresses for delivery proof and dispute resolution

This approach maintains transactional integrity while being GDPR compliant through data minimization. Orders become anonymous but retain necessary data for business operations and legal compliance.

The core technical issue remains the same (foreign key constraints blocking deletion), but the solution, as you said, would focus on anonymization rather than cascade deletion while maintaining the minimum necessary data.

Does this approach align with your vision?

[glennjacobs]

Personally, I would look to anonymise all of it. Deleting data always has some risk associated to it.

On another (non-Lunar) project we made a module that allowed us to map fields to be anonymised (with a strategy). This could then be extended with more fields to support extensions with their own personal data.

[VincentTeresa]

What you're saying makes perfect sense. I think the anonymization strategy is excellent, but I have some concerns about anonymizing order data. If a dispute arises (for example, regarding a package delivery) and the user has deleted their account, we might not have the associated data to resolve the issue. I understand that this is where the legitimate interest in data comes into play.

We can anonymize both the customer and the user, but not the order data, thus maintaining data integrity for tax or legal purposes. Otherwise, I completely agree with your proposal for anonymization rather than deletion.

Do you think this approach aligns with your vision? Or do you believe we should still anonymize everything, including shipping information?

[glennjacobs]

Oh, we'd not anonymise the order data as previously mentioned.

I do wonder if this should be in the core though. Maybe it would be better as a GDPR add-on?

[VincentTeresa]

I believe this should be part of the core rather than a separate plugin. The underlying problem is that customer deletion currently fails with foreign key constraints; this is a basic functionality that doesn't work, regardless of GDPR. Any admin panel should be able to delete customers for basic data management.

Incorporating anonymization into the core CustomerObserver also makes sense from the maintenance perspective you mentioned. A plugin would be more vulnerable with Lunar updates. But I'm willing to implement it anyway.

What do you think? What approach would you prefer for the project?

[glennjacobs]

Customer deletion should definitely be fixed in the core.

I just wonder if the anonymisation is right for the core.

@alecritson do you have any opinion on this?

[VincentTeresa]

Hi @glennjacobs,

Thanks for your valuable input on this issue, especially your suggestions about GDPR anonymization!

I've just submitted a comprehensive solution in PR #2405 that incorporates your feedback about anonymization being the preferred approach for GDPR compliance:

What i implemented:

1. GDPR-compliant anonymization as default strategy - following your recommendation
2. Configurable approach: anonymize (default) vs delete for different business needs
3. Hybrid Observer + Actions system: Resolves the original FK constraint violations
4. Intelligent orphaned user cleanup: Handles email reuse scenarios
5. Backward compatibility: Existing deletion workflows continue to work

Key features:

• Anonymization by default - addresses your GDPR concerns
• Configurable deletion strategies - flexibility for different use cases
• Comprehensive FK handling - fixes the original constraint violations
• 26 comprehensive tests covering various scenarios
• Zero breaking changes to existing functionality

Your point about anonymization being safer than deletion really influenced the design - i made it the default strategy while still providing deletion as an option for cases where it's specifically needed.

Would you mind taking a look at the PR when you have a chance? I'd really value your feedback on this approach.

Sorry for the delay in implementing this - i wanted to make sure i addressed both the immediate FK issue and the broader data lifecycle requirements you highlighted.