WooNooW/BACKEND_INTEGRATION_NEEDED.md

# ⚠️ Backend Integration Required

## Issues Found

### Issue #1: Incorrect Template Count in UI ❌

**Problem:**
The Staff Notifications page shows "9 templates" but there are only **7 staff events**.

**Location:** 
`admin-spa/src/routes/Settings/Notifications/Templates.tsx` line 132

**Current Code:**
```tsx
<Badge variant="secondary" className="text-xs">
  {allEvents.length} {__('templates')}  // ❌ Shows ALL events (customer + staff)
</Badge>
```

**Root Cause:**
- `allEvents` combines ALL event types (orders, products, customers)
- It doesn't filter by recipient type (staff vs customer)
- Shows same count for both customer and staff pages

**Expected:**
- **Customer page:** Should show 9 templates (customer events only)
- **Staff page:** Should show 7 templates (staff events only)

**Solution Needed:**
The backend API `/notifications/events` needs to return events grouped by recipient type, OR the frontend needs to filter events based on the current page (staff/customer).

---

### Issue #2: Old Templates Still Being Used ❌

**Problem:**
After reloading multiple times, the email templates shown in the editor are still using the OLD format, not the new improved markdown templates.

**Current State:**
- ✅ New templates exist: `includes/Email/DefaultTemplates.php`
- ❌ Backend still using: `includes/Core/Notifications/DefaultEmailTemplates.php`

**Evidence:**
The old `DefaultEmailTemplates.php` uses HTML-heavy syntax:
```php
'body' => '[card type="hero"]
<h1>' . __('New Order Received!', 'woonoow') . '</h1>
<p>' . __('You have received a new order...', 'woonoow') . '</p>
[/card]'
```

The new `DefaultTemplates.php` uses clean markdown:
```php
return '[card type="hero"]

New order received!

A customer has placed a new order. Please review and process.
[/card]'
```

**Root Cause:**
The backend API controller is still calling the old `DefaultEmailTemplates` class instead of the new `DefaultTemplates` class.

---

## Required Backend Changes

### 1. Update Default Templates Integration

**Option A: Replace Old Class (Recommended)**

Replace `includes/Core/Notifications/DefaultEmailTemplates.php` with a wrapper that uses the new class:

```php
<?php
namespace WooNooW\Core\Notifications;

use WooNooW\Email\DefaultTemplates as NewDefaultTemplates;

class DefaultEmailTemplates {
    
    public static function get_template($event_id, $recipient_type) {
        // Map event IDs to new template structure
        $eventMap = [
            'order_placed' => 'order_placed',
            'order_processing' => 'order_confirmed',
            'order_completed' => 'order_completed',
            'order_cancelled' => 'order_cancelled',
            'order_refunded' => 'order_cancelled', // Map to cancelled for now
            'low_stock' => 'order_placed', // Placeholder
            'out_of_stock' => 'order_placed', // Placeholder
            'new_customer' => 'customer_registered',
            'customer_note' => 'order_placed', // Placeholder
        ];
        
        $newEventId = $eventMap[$event_id] ?? $event_id;
        
        // Get templates from new class
        $allTemplates = NewDefaultTemplates::get_all_templates();
        $templates = $allTemplates[$recipient_type] ?? [];
        
        if (isset($templates[$newEventId])) {
            return [
                'subject' => NewDefaultTemplates::get_default_subject($recipient_type, $newEventId),
                'body' => $templates[$newEventId],
            ];
        }
        
        // Fallback
        return [
            'subject' => __('Notification from {store_name}', 'woonoow'),
            'body' => '[card]New notification[/card]',
        ];
    }
}
```

**Option B: Update API Controller Directly**

Update the API controller to use the new `DefaultTemplates` class:

```php
use WooNooW\Email\DefaultTemplates;

// In the get_template endpoint:
$templates = DefaultTemplates::get_all_templates();
$subject = DefaultTemplates::get_default_subject($recipient_type, $event_id);
$body = $templates[$recipient_type][$event_id] ?? '';
```

---

### 2. Fix Event Counts in API

**Update:** `includes/Api/NotificationsController.php`

The `/notifications/events` endpoint should return events with recipient type information:

```php
public function get_events($request) {
    $events = [
        'orders' => [
            [
                'id' => 'order_placed',
                'label' => __('Order Placed'),
                'description' => __('When a new order is placed'),
                'recipients' => ['customer', 'staff'], // ← Add this
            ],
            [
                'id' => 'order_confirmed',
                'label' => __('Order Confirmed'),
                'description' => __('When order is confirmed'),
                'recipients' => ['customer', 'staff'], // ← Add this
            ],
            // ... etc
        ],
        'customers' => [
            [
                'id' => 'customer_registered',
                'label' => __('Customer Registered'),
                'description' => __('When customer creates account'),
                'recipients' => ['customer'], // ← Customer only
            ],
            [
                'id' => 'customer_vip_upgraded',
                'label' => __('VIP Upgraded'),
                'description' => __('When customer becomes VIP'),
                'recipients' => ['customer'], // ← Customer only
            ],
        ],
    ];
    
    return rest_ensure_response($events);
}
```

---

### 3. Update Frontend to Filter Events

**Update:** `admin-spa/src/routes/Settings/Notifications/Templates.tsx`

```tsx
// Determine recipient type from current page
const isStaffPage = window.location.pathname.includes('/staff');
const recipientType = isStaffPage ? 'staff' : 'customer';

// Filter events by recipient
const filteredEvents = allEvents.filter((event: any) => {
  return event.recipients && event.recipients.includes(recipientType);
});

// Use filteredEvents instead of allEvents
<Badge variant="secondary" className="text-xs">
  {filteredEvents.length} {__('templates')}
</Badge>
```

---

## Event Mapping

### Customer Events (9 total)
1. `order_placed` → Order Placed
2. `order_confirmed` → Order Confirmed
3. `order_shipped` → Order Shipped
4. `order_completed` → Order Completed
5. `order_cancelled` → Order Cancelled
6. `payment_received` → Payment Received
7. `payment_failed` → Payment Failed
8. `customer_registered` → Customer Registered
9. `customer_vip_upgraded` → VIP Upgraded

### Staff Events (7 total)
1. `order_placed` → New Order
2. `order_confirmed` → Order Confirmed
3. `order_shipped` → Order Shipped
4. `order_completed` → Order Completed
5. `order_cancelled` → Order Cancelled
6. `payment_received` → Payment Received
7. `payment_failed` → Payment Failed

---

## Testing Checklist

After backend integration:

- [ ] Navigate to Customer Notifications → Templates
- [ ] Verify "9 templates" badge shows
- [ ] Open any customer event template
- [ ] Verify new markdown format is shown (not HTML)
- [ ] Navigate to Staff Notifications → Templates
- [ ] Verify "7 templates" badge shows
- [ ] Open any staff event template
- [ ] Verify new markdown format is shown
- [ ] Test saving a template
- [ ] Test resetting a template to default
- [ ] Verify preview shows correct formatting

---

## Priority

**HIGH PRIORITY** - These issues prevent the new templates from being used and show incorrect information to users.

**Estimated Time:** 1-2 hours to implement and test

---

## Summary

**What Works:**
- ✅ Frontend email builder
- ✅ Markdown parser
- ✅ Preview system
- ✅ New template files created

**What Needs Fixing:**
- ❌ Backend not using new templates
- ❌ Template count incorrect in UI
- ❌ Event-to-recipient mapping needed

**Once Fixed:**
- ✅ Users will see new improved templates
- ✅ Correct template counts
- ✅ Better UX overall