# Implementation Plan ## Validation Checklist - [x] All specification file paths are correct and exist - [x] Context priming section is complete - [x] All implementation phases are defined - [x] Each phase follows TDD: Prime → Test → Implement → Validate - [x] Dependencies between phases are clear (no circular dependencies) - [x] Parallel work is properly tagged with `[parallel: true]` - [x] Activity hints provided for specialist selection `[activity: type]` - [x] Every phase references relevant SDD sections - [x] Every test references PRD acceptance criteria - [x] Integration & E2E tests defined in final phase - [x] Project commands match actual project setup - [x] A developer could follow this plan independently --- ## Specification Compliance Guidelines ### How to Ensure Specification Adherence 1. **Before Each Phase**: Complete the Pre-Implementation Specification Gate 2. **During Implementation**: Reference specific SDD sections in each task 3. **After Each Task**: Run Specification Compliance checks 4. **Phase Completion**: Verify all specification requirements are met ### Deviation Protocol If implementation cannot follow specification exactly: 1. Document the deviation and reason 2. Get approval before proceeding 3. Update SDD if the deviation is an improvement 4. Never deviate without documentation ## Metadata Reference - `[parallel: true]` - Tasks that can run concurrently - `[component: component-name]` - For multi-component features - `[ref: document/section; lines: 1, 2-3]` - Links to specifications, patterns, or interfaces and (if applicable) line(s) - `[activity: type]` - Activity hint for specialist agent selection --- ## Context Priming *GATE: You MUST fully read all files mentioned in this section before starting any implementation.* **Specification**: - `docs/specs/008-post-event-integration-confirmation/product-requirements.md` - Product Requirements - `docs/specs/008-post-event-integration-confirmation/solution-design.md` - Solution Design **Key Design Decisions**: - **ADR-1 Hub and Spoke over Inline Expansion**: Modal-based spoke configuration instead of expanding sections inline. Complex config forms (especially Comeback Cash with 15+ fields) would clutter Step 3. - **ADR-2 SweetAlert 1.x for Confirmation Modal**: Use existing SweetAlert 1.x library with HTML content for consistency with other confirmations. - **ADR-3 Partial Success Pattern Maintained**: Event creation succeeds even if integrations fail; users can fix integrations later. **Implementation Context**: - Commands to run: ```bash ./test.sh # Run all tests ./test.sh --testsuite unit # Run unit tests only ./test.sh --testsuite integration # Run integration tests only cd userfrosting && composer install # Install dependencies ./deploy.sh # Test + deploy ``` - Patterns to follow: - Integration Adapter Pattern: `userfrosting/src/BuyerKiosk/EventManagement/Adapters/IntegrationAdapterInterface.php` - IntegrationService orchestration: `userfrosting/src/BuyerKiosk/EventManagement/Services/IntegrationService.php` - Event detail card patterns: `userfrosting/templates/themes/default/admin/event-management/detail.html` - Interfaces to implement: - Enhanced API response format: SDD Section "Internal API Changes" - Hub and Spoke navigation: SDD Section "Implementation Patterns" **Critical Files to Read Before Each Phase**: | File | Purpose | Relevance | |------|---------|-----------| | `EventApiController.php` | Event creation API (lines 251-325 create method) | HIGH - API enhancement target | | `IntegrationService.php` | Adapter orchestration patterns | CRITICAL - Must understand before any changes | | `create.html` | Current wizard Step 3 structure (lines 1047-1203) | HIGH - UI enhancement target | | `detail.html` | Integration card patterns (lines 1065-1130) | HIGH - Status badge patterns | | `event-management.css` | Existing CSS variables and card styles | MEDIUM - Style patterns | --- ## Implementation Phases ### Phase 1: API Enhancement - Integration Results Response **Goal**: Enhance EventApiController to return per-integration creation results enabling the confirmation modal. - [x] T1 Phase 1: API Enhancement `[component: backend-api]` - [x] T1.1 Prime Context - [x] T1.1.1 Read EventApiController create() method structure `[ref: userfrosting/src/BuyerKiosk/EventManagement/Controllers/EventApiController.php; lines: 251-325]` - [x] T1.1.2 Read IntegrationService createIntegration() flow `[ref: userfrosting/src/BuyerKiosk/EventManagement/Services/IntegrationService.php; lines: 136-196]` - [x] T1.1.3 Read IntegrationException handling patterns `[ref: userfrosting/src/BuyerKiosk/EventManagement/Adapters/IntegrationException.php]` - [x] T1.1.4 Review SDD Enhanced API Response specification `[ref: solution-design.md; lines: 445-484]` - [x] T1.2 Write Tests `[activity: test-development]` - [x] T1.2.1 Test: API returns integrationResults array with success entries ``` Given: Event created with 2 enabled integrations (Comeback Cash, SMS) When: POST /api/:typeNum/events Then: Response includes integrationResults with 2 entries And: Each entry has: type, status, foreignId, error fields ``` `[ref: product-requirements.md; Feature 2 acceptance criteria]` - [x] T1.2.2 Test: API returns failure entries with error messages ``` Given: Event created with integration that will fail validation When: POST /api/:typeNum/events Then: Response includes integrationResults with status="failed" And: Error message is human-readable And: Event is still created successfully (partial success) ``` `[ref: product-requirements.md; Feature 2 - partial success]` - [x] T1.2.3 Test: API returns summary counts (total_enabled, created, failed) ``` Given: Event created with 3 integrations (2 succeed, 1 fails) When: POST /api/:typeNum/events Then: Response includes summary.total_enabled=3 And: summary.created=2 And: summary.failed=1 ``` `[ref: solution-design.md; lines: 473-479]` - [x] T1.2.4 Test: Empty integrations returns empty integrationResults ``` Given: Event created with no integrations enabled When: POST /api/:typeNum/events Then: Response includes integrationResults=[] And: summary.total_enabled=0 ``` - [x] T1.3 Implement API Enhancement `[activity: backend-development]` - [x] T1.3.1 Create IntegrationResult value object class - Properties: type (string), status (enum: created/failed/skipped), foreignId (?int), error (?string) - Method: toArray() for JSON serialization `[ref: solution-design.md; lines: 521-527]` - [x] T1.3.2 Modify EventApiController::create() to collect integration results - Wrap integration processing in try-catch per integration - Build integrationResults array during processing - Build summary counts from results `[ref: solution-design.md; lines: 556-614 - Example implementation]` - [x] T1.3.3 Update JSON response to include new fields - Add integrationResults array - Add summary object with total_enabled, created, failed, skipped counts - Maintain backward compatibility (existing fields unchanged) - [x] T1.4 Implement Retry Endpoint `[activity: backend-development]` - [x] T1.4.1 Create retry endpoint: POST /api/:typeNum/events/:eventId/integrations/:type/retry `[ref: solution-design.md; lines: 489-510]` - [x] T1.4.2 Add retry count tracking per integration (max 3 attempts) - [x] T1.4.3 Return updated integration status on retry - [x] T1.5 Validate - [x] T1.5.1 Run unit tests: `./test.sh --testsuite unit` `[activity: run-tests]` - [x] T1.5.2 Run integration tests: `./test.sh --testsuite integration` `[activity: run-tests]` - [x] T1.5.3 Verify API response format matches SDD specification `[activity: specification-compliance]` - [x] T1.5.4 Test backward compatibility - existing API consumers unaffected --- ### Phase 2: Hub and Spoke UI - Integration Configuration **Goal**: Replace Step 3 toggle panels with hub and spoke navigation pattern for full integration configuration. - [x] T2 Phase 2: Hub and Spoke UI `[component: frontend-ui]` - [x] T2.1 Prime Context - [x] T2.1.1 Read current Step 3 HTML structure `[ref: userfrosting/templates/themes/default/admin/event-management/create.html; lines: 1047-1203]` - [x] T2.1.2 Read SDD hub and spoke navigation pattern `[ref: solution-design.md; lines: 866-883]` - [x] T2.1.3 Read adapter config requirements for each integration type `[ref: solution-design.md; lines: 75-106]` - [x] T2.1.4 Review PRD Feature 1 acceptance criteria `[ref: product-requirements.md; lines: 120-157]` - [x] T2.2 Integration Hub View `[parallel: true]` `[component: hub-view]` `[activity: frontend-development]` - [x] T2.2.1 Create integration-hub.html partial template - Grid layout with 7 integration cards (2 columns on desktop, 1 on mobile) - Each card: icon, name, enable toggle, config status badge - Status badges: "Not Configured" (gray), "Configured" (green with checkmark), "Incomplete" (orange) `[ref: solution-design.md; lines: 376-386]` - [x] T2.2.2 Create integration-hub.js controller - Initialize card click handlers - Manage config state per integration type - Update hub card badges on spoke save - Handle enable/disable toggle state `[ref: solution-design.md; lines: 622-680 - Example implementation]` - [x] T2.2.3 Add hub CSS styles to event-management.css - Card grid layout (flex/grid) - Toggle switch styling (match existing patterns) - Status badge colors (use CSS variables) - Hover and focus states - [x] T2.3 Integration Spoke Templates (7 types) `[parallel: true]` `[component: spoke-templates]` `[activity: frontend-development]` - [x] T2.3.1 Create comeback-cash-config.html spoke - Required fields: side (buy/sales), earning type, coupon value - Advanced Options (collapsed): tiers, earning period, redemption period, min purchase, max coupons, double-up, SMS toggle - Validation: earning type restrictions per side, period sequencing `[ref: product-requirements.md; lines: 139 - Comeback Cash fields]` `[ref: product-requirements.md; lines: 293-300 - Comeback Cash business rules]` - [x] T2.3.2 Create signage-config.html spoke - Required fields: slide selection OR tag filtering (at least one) - Advanced Options: display order, duration override - Slide picker: load from store + corporate library `[ref: product-requirements.md; lines: 140 - Signage fields]` - [x] T2.3.3 Create sms-blast-config.html spoke - Required fields: message template, send time, relative days - Advanced Options: customer segment selector - Template picker: load from existing templates `[ref: product-requirements.md; lines: 141 - SMS Blast fields]` - [x] T2.3.4 Create sms-trigger-config.html spoke - Required fields: trigger type, message template - Advanced Options: active period (relative days) `[ref: product-requirements.md; lines: 142 - SMS Trigger fields]` - [x] T2.3.5 Create task-config.html spoke - Required fields: task name - Required options: phase (prep/active/cleanup), relative days - Advanced Options: assignment target, priority level `[ref: product-requirements.md; lines: 143 - Task fields]` - [x] T2.3.6 Create note-config.html spoke - Required fields: title, content - Advanced Options: visibility toggle (manager-only), pinned toggle `[ref: product-requirements.md; lines: 144 - Note fields]` - [x] T2.3.7 Create backstock-config.html spoke - Required fields: event name - Advanced Options: category multi-select, markup adjustment, priority boost `[ref: product-requirements.md; lines: 145 - Backstock fields]` - [x] T2.4 Spoke JavaScript Controllers `[parallel: true]` `[component: spoke-controllers]` `[activity: frontend-development]` - [x] T2.4.1 Create comeback-cash-config.js validation - Buy-side restricts earning type to "flat" only - Earning period must end before redemption starts - Mirror PHP adapter validation exactly `[ref: product-requirements.md; lines: 293-300]` - [x] T2.4.2 Create signage-config.js with slide/tag picker - AJAX load slides from store/corporate library - Multi-select for tags - Require at least one slide or tag - [x] T2.4.3 Create sms-config.js for blast and trigger forms - Template selector with preview - Time picker for send time - Relative days validation (-365 to 365) - [x] T2.4.4 Create task-config.js validation - Task name max 255 chars - Phase dropdown (prep/active/cleanup) - Priority dropdown (high/normal/low) - [x] T2.4.5 Create note-config.js validation - Title max 255 chars - Content required - Toggle visibility/pinned - [x] T2.4.6 Create backstock-config.js with category picker - AJAX load categories - Multi-select for categories - Markup adjustment -100 to 100 - [x] T2.5 Spoke Modal Container `[component: spoke-modal]` `[activity: frontend-development]` - [x] T2.5.1 Create spoke-modal template with common structure - Header: integration name + icon - Body: spoke content container - Footer: "Save & Return" primary, "Cancel" secondary - ESC key closes with unsaved changes prompt - [x] T2.5.2 Integrate spoke modal into create.html Step 3 - Replace current Step 3 content with hub view - Include modal overlay container - Wire up navigation between hub ↔ spoke - [x] T2.6 Draft vs Schedule Validation `[activity: frontend-development]` - [x] T2.6.1 Implement validation logic for save mode - Draft: Allow unconfigured integrations - Schedule/Activate: Require all enabled integrations configured `[ref: product-requirements.md; lines: 152-157]` - [x] T2.6.2 Show validation error with "Configure Now" links - List incomplete integrations - Each has link to jump to that spoke - Block form submission until resolved (for schedule/activate) - [x] T2.7 Validate Hub and Spoke Implementation - [x] T2.7.1 Test hub display with all 7 integration types `[activity: ui-testing]` - [x] T2.7.2 Test spoke navigation (open, configure, save, return) `[activity: ui-testing]` - [x] T2.7.3 Test form validation for each spoke type `[activity: ui-testing]` - [x] T2.7.4 Test draft vs schedule validation logic `[activity: ui-testing]` - [x] T2.7.5 Test mobile responsiveness (tablet use) `[activity: ui-testing]` - [x] T2.7.6 Test keyboard navigation (Tab, Enter, ESC) `[activity: ui-testing]` --- ### Phase 3: Confirmation Modal **Goal**: Display post-creation confirmation showing per-integration results with retry capability. - [x] T3 Phase 3: Confirmation Modal `[component: confirmation-modal]` - [x] T3.1 Prime Context - [x] T3.1.1 Review SweetAlert 1.x patterns in codebase `[ref: solution-design.md; lines: 956-960]` - [x] T3.1.2 Read SDD confirmation modal example `[ref: solution-design.md; lines: 686-738]` - [x] T3.1.3 Review PRD Feature 3 acceptance criteria `[ref: product-requirements.md; lines: 168-183]` - [x] T3.2 Write Tests `[activity: test-development]` - [x] T3.2.1 Test: Modal displays after successful event creation ``` Given: User completes event creation wizard When: API returns success with integrationResults Then: Confirmation modal appears with event name And: Modal shows "View Event" and "Create Another" buttons ``` `[ref: product-requirements.md; lines: 170-179]` - [x] T3.2.2 Test: Modal shows success items with green checkmarks ``` Given: 3 integrations all created successfully When: Modal displays Then: Each integration shows green ✓ icon And: Summary shows "3 of 3 integrations created" ``` - [x] T3.2.3 Test: Modal shows failed items with retry buttons ``` Given: 2 integrations succeed, 1 fails When: Modal displays Then: Failed integration shows red ✗ icon And: Error message is displayed And: "Retry" button is available ``` `[ref: product-requirements.md; lines: 225-230 - retry criteria]` - [x] T3.2.4 Test: Retry updates modal row on success ``` Given: Failed integration with Retry button When: User clicks Retry and it succeeds Then: Row updates to show ✓ And: Retry button disappears ``` - [x] T3.2.5 Test: Max retries shows "Configure Manually" option ``` Given: Integration failed 3 times When: Third retry fails Then: Retry button is disabled And: "Configure Manually" link appears ``` `[ref: product-requirements.md; lines: 229-230]` - [x] T3.3 Implement Confirmation Modal `[activity: frontend-development]` - [x] T3.3.1 Create confirmation-modal.html template - Header with event name and overall status - Integration list with status icons - Success: green ✓ and type name - Failed: red ✗, type name, error message, Retry button - Summary counts at top `[ref: solution-design.md; lines: 686-738]` - [x] T3.3.2 Create confirmation-modal.js controller - Parse API response with integrationResults - Build modal HTML content - Show modal via SweetAlert 1.x - Handle button clicks (View Event, Create Another) `[ref: solution-design.md; lines: 686-738]` - [x] T3.3.3 Implement retry functionality - Bind retry button click handlers - Call retry API endpoint - Update modal row on success/failure - Disable retry after 3 attempts - Show "Configure Manually" link pointing to event detail page - [x] T3.3.4 Add keyboard navigation - Tab through buttons - Enter to activate focused button - ESC to close modal (same as X button) `[ref: product-requirements.md; lines: 181]` - [x] T3.4 Integrate with Event Form `[activity: frontend-development]` - [x] T3.4.1 Modify event-form.js submission handler - On successful create response, call showConfirmationModal() - Pass full API response to modal - Handle modal dismissal to redirect - [x] T3.5 Add Modal Styles `[activity: frontend-development]` - [x] T3.5.1 Add confirmation modal CSS - Status icon colors (green/red) - Integration list styling - Summary section styling - Retry button styling - Match existing SweetAlert customizations - [x] T3.6 Validate Confirmation Modal - [x] T3.6.1 Test modal appears after event creation `[activity: ui-testing]` - [x] T3.6.2 Test success/failure icon display `[activity: ui-testing]` - [x] T3.6.3 Test retry functionality end-to-end `[activity: integration-testing]` - [x] T3.6.4 Test keyboard navigation `[activity: ui-testing]` - [x] T3.6.5 Test "View Event" and "Create Another" navigation `[activity: ui-testing]` --- ### Phase 4: Detail Page Modal Wizard Configuration (REVISED) **Goal**: Replace simple expandable cards with full modal wizard configuration for all 7 integration types on the event detail page. **ADR-4**: Modal Wizard over Simple Expansion - provides comprehensive configuration experience without navigating away from event detail page. - [x] T4 Phase 4: Modal Wizard Configuration `[component: detail-page-wizards]` ✅ **COMPLETE** - [x] T4.1 Prime Context - [x] T4.1.1 Read current detail page integration cards `[ref: userfrosting/templates/themes/default/admin/event-management/detail.html; lines: 1065-1130]` - [x] T4.1.2 Read existing badge CSS patterns `[ref: public_html/css/admin/event-management.css]` - [x] T4.1.3 Review PRD Feature 4 acceptance criteria `[ref: product-requirements.md; lines: 184-194]` - [x] T4.1.4 Analyze all 7 integration adapter configurations `[ref: solution-design.md; Addendum section]` - [x] T4.2 IntegrationBadge Model (Retained from original) `[activity: backend-development]` - [x] T4.2.1 Create IntegrationBadge value object class - [x] T4.2.2 Write unit tests for badge logic (30 tests) - [x] T4.2.3 Implement badge priority: Setup Required > New > Status - [x] T4.3 Wizard Infrastructure `[activity: frontend-development]` - [x] T4.3.1 Create base WizardModal.js class (~1500 lines) - Constructor with integrationId, integrationType, config - Step management: nextStep(), prevStep(), goToStep() - Validation hooks per step - Modal open/close with unsaved changes detection - Save API call handler - Injected CSS styles `[ref: solution-design.md; Addendum - JavaScript Architecture]` - [x] T4.3.2 Step helper methods in WizardModal.js - Step validation - Field value extraction via collectFormData() - Inline error display via showStepErrors() - Step transition animation - [x] T4.3.3 Modal rendered dynamically via JavaScript - Large modal container (720px max-width, 85vh max-height) - Step indicator bar - Scrollable body container - Footer with Back/Next/Save/Cancel buttons `[ref: solution-design.md; Addendum - Modal Container spec]` - [x] T4.3.4 CSS injected by WizardModal.injectStyles() - .wizard-modal container - .wizard-steps indicator bar - .wizard-step-indicator states (active, completed) - .wizard-step-dot styling - .wizard-body scrollable area - .wizard-footer button layout `[ref: solution-design.md; Addendum - CSS Additions]` - [x] T4.4 Comeback Cash Wizard (Template - Most Complex) `[parallel: false]` `[activity: frontend-development]` - [x] T4.4.1 Create ComebackCashWizard.js (extends WizardModal) - 4 steps: Side → Earning → Redemption → Review - Side selection affects earning type options (buy = flat only) - Earning period validation (must end before redemption starts) - Complex field dependencies - [x] T4.4.2 Step 1: Side Selection - Radio buttons: Buy Side / Sales Side - Description of each side's purpose - [x] T4.4.3 Step 2: Earning Configuration - Earning type radio: Flat/Percentage/Tiered (Flat only if buy-side) - Conditional fields based on earning type - Flat: earningFlatAmount (currency input) - Percentage: earningPercentage (0.1-100%) - Tiered: tier builder component (min, max, reward) - Optional: minPurchaseToEarn, earningStartRelative, earningEndRelative - [x] T4.4.4 Step 3: Redemption Configuration - Required: couponValue (currency) - Optional: redemptionStartRelative, redemptionEndRelative - Optional: redemptionMinPurchase, maxCouponsPerCustomer - Checkbox: allowDoubleUp (sales-side only) - Checkbox: smsNotification (default true) - Select: refundPolicy (Forfeit/Refund) - [x] T4.4.5 Step 4: Review - Summary of all configured options - Edit links back to each step - Final validation display - [x] T4.4.6 Validation per step implemented - Buy-side restricts to flat earning type - Earning period ends before redemption starts - Required field validation per step - Tier overlap detection - [x] T4.5 Digital Signage Wizard `[parallel: true]` `[activity: frontend-development]` - [x] T4.5.1 Create SignageWizard.js (2 steps) - [x] T4.5.2 Step 1: Source Selection (Store/Corporate/Hipbone radio) - [x] T4.5.3 Step 2: Slide Selection - Async slide loader based on source - Multi-select slide picker OR tag multi-select - Optional: displayOrder, duration - [x] T4.5.4 Implement slide loading API integration - [x] T4.6 SMS Blast Wizard `[parallel: true]` `[activity: frontend-development]` - [x] T4.6.1 Create SmsBlastWizard.js (2 steps) - [x] T4.6.2 Step 1: Message Selection (template picker with preview) - [x] T4.6.3 Step 2: Scheduling - relativeDays (days from event start) - sendTime (HH:MM picker) - segment (All/VIP/Active30/Active90/OptedIn) - [x] T4.7 SMS Trigger Wizard `[parallel: true]` `[activity: frontend-development]` - [x] T4.7.1 Create SmsTriggerWizard.js (2 steps) - [x] T4.7.2 Step 1: Message Selection (template picker with preview) - [x] T4.7.3 Step 2: Trigger Configuration - triggerType select (on_purchase, on_coupon_earn, etc.) - startRelativeDays, endRelativeDays - [x] T4.8 Task Wizard `[parallel: true]` `[activity: frontend-development]` - [x] T4.8.1 Create TaskWizard.js (2 steps) - [x] T4.8.2 Step 1: Task Details - taskName (max 255 chars) - phase (Prep/Active/Cleanup) - relativeDays - notes textarea - [x] T4.8.3 Step 2: Assignment - assignTo (Creator/Manager/All/Specific) - assignToUser (conditional user picker) - priority (High/Normal/Low) - createGroup checkbox - [x] T4.9 Note Wizard (Single-Step) `[parallel: true]` `[activity: frontend-development]` - [x] T4.9.1 Create NoteWizard.js (single step, no step indicator) - [x] T4.9.2 Note form fields - title (max 255), content (textarea) - startRelativeDays, endRelativeDays - isManagerOnly, isPinned checkboxes - [x] T4.10 Backstock Wizard (Single-Step) `[parallel: true]` `[activity: frontend-development]` - [x] T4.10.1 Create BackstockWizard.js (single step) - [x] T4.10.2 Backstock form fields - name (max 100) - categories multi-select (async load) - markupAdjustment slider (-100 to 100) - priorityBoost checkbox - [x] T4.11 Detail Page Integration `[activity: frontend-development]` - [x] T4.11.1 Update detail.html integration cards - Add data-integration-id and data-type attributes - Add click handler to open wizard modal - Show config summary in card body - Display IntegrationBadge status badges - [x] T4.11.2 Add badge CSS classes - .badge-new (blue) - .badge-setup (amber) - Clickable card styles - Setup prompt styling - [x] T4.11.3 Wire up wizard initialization - Load existing integration config on card click - Initialize appropriate wizard class by type - Handle save callback to refresh card - Wizard registration system for type mapping - [x] T4.12 API Endpoints `[activity: backend-development]` - [x] T4.12.1 GET /api/:typeNum/events/:eventId/integrations/:integrationId - Return full integration config for wizard pre-population - [x] T4.12.2 PUT /api/:typeNum/events/:eventId/integrations/:integrationId - Accept updated config - Re-validate through adapter - Return updated integration object - [x] T4.13 Validate Modal Wizard Implementation - [x] T4.13.1 All 8 JavaScript files pass syntax check - [x] T4.13.2 All 1598 unit tests pass - [ ] T4.13.3 Manual testing pending for step navigation `[activity: ui-testing]` - [ ] T4.13.4 Manual testing pending for save flow `[activity: integration-testing]` - [ ] T4.13.5 Manual testing pending for keyboard navigation `[activity: ui-testing]` - [ ] T4.13.6 Manual testing pending for unsaved changes prompt `[activity: ui-testing]` - [ ] T4.13.7 Manual testing pending for mobile/tablet responsiveness `[activity: ui-testing]` --- ### Phase 5: Edit Mode Enhancements (Streamlined - Core Merged into Phase 4) **Goal**: Add edit-specific features beyond what Phase 4 modal wizards provide. **Note**: The core edit functionality (opening wizards with pre-populated data, saving changes) is now part of Phase 4. This phase covers edit-specific enhancements. - [x] T5 Phase 5: Edit Mode Enhancements `[component: edit-mode]` - [x] T5.1 Add New Integration to Existing Event `[activity: frontend-development]` - [x] T5.1.1 Add "Add Integration" button to detail page integration section - [x] T5.1.2 Show integration type picker modal (7 options) - [x] T5.1.3 Open appropriate wizard for new integration - [x] T5.1.4 POST to create new integration linked to existing event - [x] T5.2 Disable Integration with Confirmation `[activity: frontend-development]` - [x] T5.2.1 Add disable toggle to integration card actions - [x] T5.2.2 Check for associated data before disable - Comeback Cash: count issued coupons - Tasks: count tasks created - Notes: count notes - SMS: count messages sent - [x] T5.2.3 Show warning dialog with record count - [x] T5.2.4 Require confirmation before disabling - [x] T5.2.5 Implement soft-disable (preserve data, mark inactive) - [x] T5.3 Bulk Integration Operations `[activity: frontend-development]` - [x] T5.3.1 Add "Edit All Integrations" button to hub view - [x] T5.3.2 Show summary of all pending changes before save - [x] T5.3.3 Implement batch save API call - [x] T5.4 Validate Edit Mode Enhancements - [x] T5.4.1 Test adding new integration to existing event `[activity: ui-testing]` - [x] T5.4.2 Test disable confirmation with data `[activity: ui-testing]` - [x] T5.4.3 Test bulk edit workflow `[activity: ui-testing]` - [x] T5.4.5 Test validation on scheduled event edit `[activity: ui-testing]` --- ### Phase 6: Integration & End-to-End Validation **Goal**: Comprehensive testing and validation of all implemented features. - [ ] T6 Integration & End-to-End Validation - [ ] T6.1 Unit Test Coverage - [ ] T6.1.1 All EventApiController tests passing `[activity: run-tests]` - [ ] T6.1.2 All IntegrationResult tests passing `[activity: run-tests]` - [ ] T6.1.3 Run: `./test.sh --testsuite unit --coverage` - [ ] T6.2 Integration Tests - [ ] T6.2.1 Test complete event creation flow with integrations - Create event → Configure all 7 integrations → Save → Verify modal `[ref: solution-design.md; lines: 969-978 - Scenario 1]` - [ ] T6.2.2 Test partial success scenario - Create event with failing integration → Verify modal shows failure → Retry `[ref: solution-design.md; lines: 980-991 - Scenario 2]` - [ ] T6.2.3 Run: `./test.sh --testsuite integration` - [ ] T6.3 End-to-End Tests - [ ] T6.3.1 Manual E2E: Complete wizard flow 1. Navigate to /admin/{typeNum}/events/create 2. Complete Step 1-2 3. Configure integrations in Step 3 hub/spoke 4. Review in Step 4 5. Create event 6. Verify confirmation modal 7. Navigate to detail page 8. Verify integration status badges - [ ] T6.3.2 Manual E2E: Edit existing event integrations 1. Open event detail page 2. Click "Edit Integrations" 3. Modify integration config 4. Save changes 5. Verify changes reflected - [ ] T6.3.3 Manual E2E: Mobile/tablet responsiveness 1. Complete wizard on tablet-sized viewport 2. Verify hub card grid adjusts 3. Verify spoke modals work on touch - [ ] T6.4 Performance Validation - [ ] T6.4.1 Spoke modal opens in < 200ms `[ref: solution-design.md; line: 930]` - [ ] T6.4.2 Event creation API responds in < 3 seconds with all integrations `[ref: solution-design.md; line: 931]` - [ ] T6.4.3 Confirmation modal displays immediately after API response `[ref: solution-design.md; line: 932]` - [ ] T6.5 Security Validation - [ ] T6.5.1 Verify uri_events_manage permission enforced on all new endpoints `[activity: security-testing]` - [ ] T6.5.2 Verify CSRF protection on form submissions `[activity: security-testing]` - [ ] T6.5.3 Verify store isolation via checkStoreGroup() `[activity: security-testing]` - [ ] T6.6 Acceptance Criteria Verification - [ ] T6.6.1 Verify all PRD Feature 1 acceptance criteria met `[ref: product-requirements.md; lines: 120-157]` - [ ] T6.6.2 Verify all PRD Feature 2 acceptance criteria met `[ref: product-requirements.md; lines: 162-166]` - [ ] T6.6.3 Verify all PRD Feature 3 acceptance criteria met `[ref: product-requirements.md; lines: 170-182]` - [ ] T6.6.4 Verify all PRD Feature 4 acceptance criteria met `[ref: product-requirements.md; lines: 186-194]` - [ ] T6.6.5 Verify all PRD Feature 5 acceptance criteria met `[ref: product-requirements.md; lines: 199-217]` - [ ] T6.6.6 Verify PRD Feature 6 (Should Have - Retry) acceptance criteria met `[ref: product-requirements.md; lines: 225-230]` - [ ] T6.7 Documentation & Deployment - [ ] T6.7.1 Update any API documentation for new response format - [ ] T6.7.2 Test coverage meets standards (≥80%) - [ ] T6.7.3 Run full build verification: `./deploy.sh` (tests + deploy) - [ ] T6.7.4 Verify deployment success on staging environment --- ## Deployment Strategy ### Pre-Deployment Checklist - [ ] All unit tests passing - [ ] All integration tests passing - [ ] Manual E2E tests completed - [ ] Performance benchmarks met - [ ] Security validation passed - [ ] Code reviewed and approved ### Deployment Steps 1. Run `./deploy.sh` which executes tests before deploying 2. Verify deployment on staging environment 3. Test key flows: - Create event with integrations - View confirmation modal - Check detail page badges 4. Monitor for errors in first 24 hours 5. Collect user feedback on new UI ### Rollback Plan If issues arise post-deployment: 1. Revert to previous commit: `git revert HEAD` 2. Redeploy: `./deploy.sh` 3. Document issues for fix in next iteration --- ## Phase Dependencies ```mermaid graph TD T1[Phase 1: API Enhancement] --> T3[Phase 3: Confirmation Modal] T2[Phase 2: Hub and Spoke UI] --> T3 T2 --> T5[Phase 5: Edit Mode] T1 --> T4[Phase 4: Detail Page] T3 --> T6[Phase 6: Integration Testing] T4 --> T6 T5 --> T6 ``` **Parallel Opportunities**: - Phase 2 (Hub/Spoke UI) can run in parallel with Phase 1 (API Enhancement) - Phase 4 (Detail Page) can start after Phase 1 completes - Phase 3 (Confirmation Modal) requires both Phase 1 and Phase 2 **Critical Path**: Phase 1 → Phase 3 → Phase 6 --- ## Success Criteria From PRD Section "Success Metrics": | KPI | Target | Measurement | |-----|--------|-------------| | Adoption | 80% of events use full config UI | `event_wizard_step_completed` tracking | | Engagement | +30% time in Step 3 | `time_on_step` property | | Quality | >95% integration success rate | `event_created` integrations_succeeded | | Business Impact | -50% support tickets for missing integrations | Support ticket analysis | --- ## Risk Mitigation | Risk | Mitigation | |------|------------| | JavaScript validation doesn't match PHP validation | Mirror adapter validation rules exactly; add validation comparison tests | | SweetAlert 1.x HTML limitations | Test HTML content rendering early; have fallback simpler design | | Complex Comeback Cash configuration overwhelms users | Progressive disclosure with clear required vs advanced sections | | Edit mode introduces data inconsistency | Add confirmation dialogs for destructive actions; preserve config on disable |