Prepare project for pipeline takeover: task tracker, UX doc, CLAUDE.md pointers
Adds docs/tasks/ (16 epics + 102 stories converted to task/subtask files with statuses.md as the new status source of truth) and docs/ux-design.md (retrospective design-system reference), and points CLAUDE.md at them. docs/prd.md and docs/architecture.md are kept as BMAD wrote them; the legacy docs/stories/, docs/epics/, docs/qa/gates/ and .bmad-core/ stay in place as historical/traceability records, superseded but not deleted. Co-Authored-By: Claude Sonnet 5 <noreply@anthropic.com>
This commit is contained in:
Naser Mansour
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: 1-1
|
||||
title: 1-1 Project Setup & Database Schema
|
||||
status: Done
|
||||
date: 2026-09-27
|
||||
parent: 1
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer, I want the Laravel 12 project configured with all required packages and complete database schema, So that the foundation is established for all subsequent feature development. Full implementation history: docs/stories/story-1.1-project-setup-database-schema.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Laravel 12 project created with Livewire 3, Volt, Flux UI
|
||||
- [ ] Tailwind CSS 4 configured with `@theme` directive
|
||||
- [ ] Database migrations for all core tables:
|
||||
- [ ] Model factories created for testing
|
||||
- [ ] Development environment working (`composer run dev`)
|
||||
- [ ] SQLite configured for development database
|
||||
- [ ] All migrations run without errors
|
||||
- [ ] Factories generate valid test data
|
||||
- [ ] All database tables have proper indexes
|
||||
- [ ] Foreign key constraints properly defined
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: 1-2
|
||||
title: 1-2 Authentication & Role System
|
||||
status: Done
|
||||
date: 2026-09-27
|
||||
parent: 1
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want a secure authentication system with Admin/Client roles, So that only authorized users can access the platform with appropriate permissions. Full implementation history: docs/stories/story-1.2-authentication-role-system.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Fortify configured with custom Volt views
|
||||
- [ ] Login page with bilingual support (Arabic/English)
|
||||
- [ ] Session timeout after 2 hours of inactivity
|
||||
- [ ] Rate limiting on login attempts (5 attempts per minute)
|
||||
- [ ] Admin role with full access to all features
|
||||
- [ ] Client role with restricted access (own data only)
|
||||
- [ ] Registration feature DISABLED (admin creates all accounts)
|
||||
- [ ] CSRF protection enabled on all forms
|
||||
- [ ] Password hashing using bcrypt
|
||||
- [ ] Custom middleware for admin authorization
|
||||
- [ ] Secure session configuration
|
||||
- [ ] Remember me functionality (optional)
|
||||
- [ ] Login redirects to appropriate dashboard:
|
||||
- [ ] Logout clears session properly and redirects to login page
|
||||
- [ ] Admin middleware protects admin-only routes (return 403 for unauthorized)
|
||||
- [ ] Failed login attempts logged to `admin_logs` table
|
||||
- [ ] Deactivated users cannot log in
|
||||
- [ ] Login form validates inputs properly
|
||||
- [ ] Error messages are clear and bilingual
|
||||
- [ ] All test scenarios in "Testing" section pass
|
||||
- [ ] No security vulnerabilities
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: 1-3
|
||||
title: 1-3 Bilingual Infrastructure (Arabic/English)
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 1
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a user (admin or client), I want full bilingual support with Arabic as primary and English as secondary language, So that I can use the platform in my preferred language with proper RTL/LTR layout. Context: Integrates with: Laravel localization, Tailwind CSS, user preferences; Technology: Laravel lang files, Tailwind RTL, Google Fonts; Follows pattern: Laravel localization best practices. Full implementation history: docs/stories/story-1.3-bilingual-infrastructure.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Language files for Arabic (ar) and English (en)
|
||||
- [ ] Language toggle in navigation (visible on all pages)
|
||||
- [ ] User language preference stored in `users.preferred_language`
|
||||
- [ ] Guest language stored in session (persists across page loads)
|
||||
- [ ] RTL layout for Arabic, LTR for English
|
||||
- [ ] All UI elements translatable via `__()` helper
|
||||
- [ ] Language switch preserves current page (redirect back to same URL)
|
||||
- [ ] Form validation messages display in current locale
|
||||
- [ ] Missing translations fall back to key name (not break page)
|
||||
- [ ] Arabic: DD/MM/YYYY format
|
||||
- [ ] English: MM/DD/YYYY format
|
||||
- [ ] Both: 12-hour time format (AM/PM)
|
||||
- [ ] Both: Western numerals (123) - no Arabic numerals
|
||||
- [ ] Arabic fonts: Cairo or Tajawal (Google Fonts)
|
||||
- [ ] English fonts: Montserrat or Lato (Google Fonts)
|
||||
- [ ] Font weights: 300, 400, 600, 700
|
||||
- [ ] font-display: swap for performance
|
||||
- [ ] Language middleware sets locale from user preference or session
|
||||
- [ ] Direction attribute (`dir="rtl"` or `dir="ltr"`) on HTML element
|
||||
- [ ] Tailwind RTL utilities working
|
||||
- [ ] Forms align correctly in both directions
|
||||
- [ ] No hardcoded strings in views
|
||||
- [ ] All translation keys organized by feature
|
||||
- [ ] Tests verify language switching
|
||||
- [ ] No layout breaks when switching languages
|
||||
@@ -0,0 +1,50 @@
|
||||
---
|
||||
id: 1-4
|
||||
title: 1-4 Base UI & Navigation
|
||||
status: Done
|
||||
date: 2026-09-27
|
||||
parent: 1
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor or logged-in user, I want a professional, responsive navigation system with brand colors, So that I can easily navigate the platform on any device. Context: Integrates with: Flux UI Free, Tailwind CSS 4, bilingual system; Technology: Livewire Volt, Flux UI components, Alpine.js; Follows pattern: Flux UI navbar patterns, mobile-first design. - **Logo SVG:** Required at public/images/logo.svg - **Fallback:** Text "Libra" in gold displayed if logo asset not available - **Logo Specs:** SVG format preferred, min 120px width desktop, 80px mobile - **Note:** Logo asset to be provided by client; use text fallback during development. Full implementation history: docs/stories/story-1.4-base-ui-navigation.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Primary: Dark Navy Blue (#0A1F44) - backgrounds, headers
|
||||
- [ ] Accent: Gold (#D4AF37) - buttons, links, accents
|
||||
- [ ] Light Gold: #F4E4B8 - hover states
|
||||
- [ ] Off-White/Cream: #F9F7F4 - cards, content areas
|
||||
- [ ] Charcoal Gray: #2C3E50 - secondary text
|
||||
- [ ] Custom Tailwind colors configured via @theme
|
||||
- [ ] Fixed top position
|
||||
- [ ] Navy blue background
|
||||
- [ ] Logo placement: left on desktop, centered on mobile
|
||||
- [ ] Main menu items: Home, Booking, Posts, Login/Dashboard
|
||||
- [ ] Language toggle (Arabic/English) visible
|
||||
- [ ] Responsive mobile hamburger menu
|
||||
- [ ] Gold text for links, hover effects
|
||||
- [ ] Full-width dropdown or slide-in
|
||||
- [ ] Navy background with gold text
|
||||
- [ ] Touch-friendly targets (44px+ height)
|
||||
- [ ] Smooth open/close animation
|
||||
- [ ] Close on outside click or navigation
|
||||
- [ ] Navy blue background
|
||||
- [ ] Libra logo (smaller version)
|
||||
- [ ] Firm contact information
|
||||
- [ ] Links: Terms of Service, Privacy Policy
|
||||
- [ ] Copyright notice with current year
|
||||
- [ ] Sticky footer (always at bottom of viewport)
|
||||
- [ ] Card-based layouts with proper shadows and border-radius
|
||||
- [ ] Consistent spacing using Tailwind utilities
|
||||
- [ ] Container max-width: 1200px, centered
|
||||
- [ ] WCAG AA contrast compliance verified
|
||||
- [ ] Flux UI components used where available
|
||||
- [ ] Works with RTL and LTR layouts
|
||||
- [ ] Navigation state reflects current page
|
||||
- [ ] Login/logout state reflected in menu
|
||||
- [ ] Responsive on all breakpoints (mobile, tablet, desktop)
|
||||
- [ ] No horizontal scroll on any viewport
|
||||
- [ ] Fast loading (minimal CSS/JS)
|
||||
- [ ] Tests verify navigation rendering
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 1
|
||||
title: 1 Core Foundation & Infrastructure
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Establishes the foundational Laravel 12 application: authentication with Admin/Client roles via Fortify, full bilingual (Arabic/English) infrastructure with RTL/LTR layout switching, and the base UI/navigation shell that every later epic builds on.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Laravel 12 project configured and running
|
||||
- [ ] Database schema designed and migrations created
|
||||
- [ ] Fortify authentication working (login only, no self-registration)
|
||||
- [ ] Admin and Client roles implemented with proper authorization
|
||||
- [ ] Bilingual infrastructure (Arabic primary, English secondary)
|
||||
- [ ] RTL/LTR layout switching functional
|
||||
- [ ] Base UI framework with brand colors (Navy #0A1F44, Gold #D4AF37)
|
||||
- [ ] Navigation system with language toggle
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 10-1
|
||||
title: 10-1 Core CSS Theme Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update the Tailwind CSS theme color variables So that the application uses the new LIBRA for Rights brand palette. - resources/css/app.css - Main theme file. Full implementation history: docs/stories/story-10.1-core-css-theme-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Update Color Variables in `resources/css/app.css`: Given the current theme uses Navy Blue + Gold palette; When I update the `@theme` block; Then the following color mappings are applied:
|
||||
- [ ] AC2: Maintain Backward Compatibility Aliases: Given existing components use `navy`, `gold`, `cream` class names; When the theme is updated; Then aliases are created so existing classes continue to work:
|
||||
- [ ] AC3: Update Semantic Aliases: Given semantic aliases exist for components; When theme is updated; Then these mappings are correct:
|
||||
- [ ] AC4: Update Button Styles: Given button classes use gold/navy colors; When theme is updated; Then `.btn-primary` and `.btn-secondary` use new palette:
|
||||
- [ ] AC5: Update Form Focus States: Given form inputs have gold focus rings; When theme is updated; Then focus states use Warm Gray:
|
||||
- [ ] AC6: Update Prose Class: Given `.prose-navy` class exists for blog content; When theme is updated; Then rename to `.prose-brand` or update colors:
|
||||
- [ ] AC7: Status Colors Unchanged: Given status colors serve functional purposes; When theme is updated; Then these remain unchanged:
|
||||
- [ ] AC8: WCAG AA Contrast Compliance: Given accessibility requirements; When new colors are applied; Then all text/background combinations meet WCAG AA:
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 10-2
|
||||
title: 10-2 Blade Component Color Migration
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update all Blade components and pages to use the new color palette So that the entire application has consistent branding. Full implementation history: docs/stories/story-10.2-blade-component-color-migration.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Navigation Component Updated: Given `resources/views/components/navigation.blade.php` uses old colors; When I update the component; Then the following changes are applied:
|
||||
- [ ] AC2: Footer Component Updated: Given `resources/views/components/footer.blade.php` uses old colors; When I update the component; Then the following changes are applied:
|
||||
- [ ] AC3: Logo Component Updated: Given `resources/views/components/logo.blade.php` references logo files; When I update the component; Then it references the correct logo variant for the background
|
||||
- [ ] AC4: Language Toggle Updated: Given `resources/views/components/language-toggle.blade.php` uses old colors; When I update the component; Then colors match new palette
|
||||
- [ ] AC5: Card Components Updated: Given card components use old colors; When I update `resources/views/components/ui/card.blade.php`; Then the following changes are applied:
|
||||
- [ ] AC6: Stat Card Component Updated: Given `resources/views/components/ui/stat-card.blade.php` uses old colors; When I update the component; Then colors match new palette
|
||||
- [ ] AC7: Spinner Component Updated: Given `resources/views/components/spinner.blade.php` uses old colors; When I update the component; Then spinner uses Charcoal or Warm Gray
|
||||
- [ ] AC8: Toast Component Updated: Given `resources/views/components/toast.blade.php` uses old colors; When I update the component; Then colors match new palette (status colors remain unchanged)
|
||||
- [ ] AC9: Public Pages Updated: Given public pages use old colors; When I update the following pages; Then they use the new palette:
|
||||
- [ ] AC10: Post Pages Updated: Given post display pages use old colors; When I update the following pages; Then they use the new palette:
|
||||
- [ ] AC11: Public Layout Updated: Given `resources/views/components/layouts/public.blade.php` uses old colors; When I update the layout; Then it uses the new palette
|
||||
- [ ] AC12: RTL Layout Integrity: Given the application supports RTL (Arabic); When colors are updated; Then RTL layout displays correctly with new colors
|
||||
- [ ] AC13: Responsive Appearance: Given the application is responsive; When colors are updated; Then all breakpoints display correctly (mobile, tablet, desktop)
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 10-3
|
||||
title: 10-3 Email Template Color Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update email templates to use the new brand colors So that all email communications reflect the new LIBRA for Rights branding. **Theme CSS:** - resources/views/vendor/mail/html/themes/default.css. Full implementation history: docs/stories/story-10.3-email-template-color-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Email Theme CSS Updated: Given `resources/views/vendor/mail/html/themes/default.css` uses old colors; When I update the stylesheet; Then the following changes are applied:
|
||||
- [ ] AC2: Email Header Component Updated: Given `resources/views/vendor/mail/html/header.blade.php` may have inline styles; When I update the component; Then any inline color references use new palette
|
||||
- [ ] AC3: Email Footer Component Updated: Given `resources/views/vendor/mail/html/footer.blade.php` may have inline styles; When I update the component; Then any inline color references use new palette
|
||||
- [ ] AC4: Button Component Updated: Given `resources/views/vendor/mail/html/button.blade.php` may have inline styles; When I update the component; Then primary buttons use:
|
||||
- [ ] AC5: Panel Component Updated: Given `resources/views/vendor/mail/html/panel.blade.php` may have inline styles; When I update the component; Then panel border uses Warm Gray (`#C9C4BA`)
|
||||
- [ ] AC6: Email Logo Updated: Given email header displays the logo; When emails are sent; Then the logo matches the new brand identity
|
||||
- [ ] AC7: All Email Templates Tested: Given the application sends various email types; When I test each email template; Then colors display correctly:
|
||||
- [ ] AC8: Plain Text Fallback Unaffected: Given plain text email templates exist; When colors are updated; Then plain text templates continue to work (no color changes needed)
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 10-4
|
||||
title: 10-4 PDF Template Color Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update PDF export templates to use the new brand colors So that all exported documents reflect the new LIBRA for Rights branding. **PDF Templates:** - resources/views/pdf/users-export.blade.php - resources/views/pdf/consultations-export.blade.php - resources/views/pdf/timelines-export.blade.php - resources/views/pdf/monthly-report.blade.php. Full implementation history: docs/stories/story-10.4-pdf-template-color-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Users Export PDF Updated: Given `resources/views/pdf/users-export.blade.php` uses old colors; When I update the template; Then the following changes are applied:
|
||||
- [ ] AC2: Consultations Export PDF Updated: Given `resources/views/pdf/consultations-export.blade.php` uses old colors; When I update the template; Then colors match the new brand palette
|
||||
- [ ] AC3: Timelines Export PDF Updated: Given `resources/views/pdf/timelines-export.blade.php` uses old colors; When I update the template; Then colors match the new brand palette
|
||||
- [ ] AC4: Monthly Report PDF Updated: Given `resources/views/pdf/monthly-report.blade.php` uses old colors; When I update the template; Then the following changes are applied:
|
||||
- [ ] AC5: Monthly Report Service Updated: Given `app/Services/MonthlyReportService.php` may contain color references; When I review the service; Then any hardcoded colors are updated to new palette
|
||||
- [ ] AC6: PDF Logo Updated: Given PDF templates include the logo; When PDFs are generated; Then the logo matches the new brand identity
|
||||
- [ ] AC7: Print-Friendly Colors: Given PDFs are often printed; When colors are updated; Then they remain legible when printed in grayscale
|
||||
- [ ] AC8: All PDF Exports Tested: Given the admin can export various data types; When I test each PDF export; Then colors display correctly and documents are professional
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 10-5
|
||||
title: 10-5 Logo and SVG Assets Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update all logo files and SVG assets to match the new brand So that the application displays the correct LIBRA for Rights logo everywhere. **Logo Files:** - public/images/logo.svg - Primary full-color logo - public/images/logo-reversed.svg - For dark backgrounds - public/images/logo-mono.svg - Single-color version - public/images/logo.png - PNG fallback. Full implementation history: docs/stories/story-10.5-logo-assets-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Primary Logo Updated: Given `public/images/logo.svg` contains the old Scales of Justice logo with gold colors; When I update or replace the logo; Then the new botanical/wheat logo is displayed with correct colors:
|
||||
- [ ] AC2: Reversed Logo Updated: Given `public/images/logo-reversed.svg` is for dark backgrounds; When I update or replace the logo; Then the logo displays correctly on Charcoal backgrounds:
|
||||
- [ ] AC3: Monochrome Logo Updated: Given `public/images/logo-mono.svg` exists for single-color applications; When I update or replace the logo; Then the logo uses appropriate single color from new palette
|
||||
- [ ] AC4: PNG Logo Updated: Given `public/images/logo.png` is used in some contexts; When I update or replace the logo; Then the PNG matches the new SVG logo
|
||||
- [ ] AC5: Favicon Updated: Given the application has a favicon; When I review favicon files; Then they are updated to match new brand (if applicable)
|
||||
- [ ] AC6: Logo Component References Correct Files: Given `resources/views/components/logo.blade.php` references logo files; When I review the component; Then it uses the correct logo variant based on context (light/dark background)
|
||||
- [ ] AC7: Logo Displays Correctly Throughout App: Given the logo appears in multiple locations; When logos are updated; Then they display correctly in:
|
||||
- [ ] AC8: Logo Clear Space Maintained: Given brand guidelines specify clear space around logo; When logo is displayed; Then minimum padding/margin is maintained as per `docs/brand.md`
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 10-6
|
||||
title: 10-6 Documentation Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 10
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update all documentation to reflect the new brand colors So that future development references accurate color information. **Core Documentation:** - CLAUDE.md - docs/prd.md - docs/architecture.md - docs/brand.md (verify accuracy). Full implementation history: docs/stories/story-10.6-documentation-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: CLAUDE.md Updated: Given `CLAUDE.md` contains color guidance; When I update the file; Then the following sections are updated:
|
||||
- [ ] AC2: PRD Updated: Given `docs/prd.md` contains detailed color specifications; When I update the document; Then the following sections are updated:
|
||||
- [ ] AC3: Architecture Document Updated: Given `docs/architecture.md` may contain color references; When I review and update the document; Then any color references are updated to new palette
|
||||
- [ ] AC4: Epic 9 Stories Referenced as Superseded: Given Epic 9 stories implemented the original Navy+Gold palette; When I review Epic 9 story files; Then a note is added indicating colors were updated in Epic 10:
|
||||
- [ ] AC5: Epic 10 Document Updated: Given `docs/epics/epic-10-brand-color-refresh.md` exists; When all stories are complete; Then the epic document is updated with completion status
|
||||
- [ ] AC6: brand.md Verified Accurate: Given `docs/brand.md` defines the new brand; When I review the document; Then it accurately describes:
|
||||
- [ ] AC7: No Stale Color References: Given documentation should be accurate; When I search all markdown files for old hex values; Then no references to old colors remain:
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: 10
|
||||
title: 10 Brand Color Refresh
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
A brownfield color migration replacing the original Navy+Gold palette with a Charcoal + Warm Gray earth-tone palette across the whole application: core CSS theme, all Blade components, email templates, PDF templates, logo/SVG assets, and documentation. Superseded again by Epic 12.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Story 10.1: Core CSS theme updated with new colors
|
||||
- [ ] Story 10.2: All Blade components using new palette
|
||||
- [ ] Story 10.3: Email templates updated
|
||||
- [ ] Story 10.4: PDF templates updated
|
||||
- [ ] Story 10.5: Logo files updated/replaced
|
||||
- [ ] Story 10.6: All documentation updated
|
||||
- [ ] All pages render correctly with new colors
|
||||
- [ ] WCAG AA contrast compliance verified
|
||||
- [ ] RTL layout displays correctly
|
||||
- [ ] Responsive design intact across breakpoints
|
||||
- [ ] PDF exports display new branding
|
||||
- [ ] Email templates display new branding
|
||||
- [ ] Code formatted with Pint
|
||||
- [ ] All existing tests passing
|
||||
- [ ] Visual QA completed on all major pages
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 11-1
|
||||
title: 11-1 Database Schema & Model Updates
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 11
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer, I want to extend the consultation system to support guest bookings, So that consultations can be created for both registered clients and anonymous guests. The existing foreign key consultations_user_id_foreign cascades on delete. With nullable user_id: - Guest consultations won't be affected by user deletions (they have no user) - Client consultations still cascade delete when user is deleted. Full implementation history: docs/stories/story-11.1-database-schema-model-updates.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `user_id` column changed to nullable on `consultations` table
|
||||
- [ ] `guest_name` column added (varchar 255, nullable)
|
||||
- [ ] `guest_email` column added (varchar 255, nullable)
|
||||
- [ ] `guest_phone` column added (varchar 50, nullable)
|
||||
- [ ] Index added on `guest_email` for 1-per-day lookup performance
|
||||
- [ ] Migration is reversible without data loss
|
||||
- [ ] Existing consultations with `user_id` unaffected
|
||||
- [ ] `Consultation` model updated with new fillable fields
|
||||
- [ ] `isGuest()` helper method returns true when `user_id` is null
|
||||
- [ ] `getClientName()` helper returns guest_name or user->full_name
|
||||
- [ ] `getClientEmail()` helper returns guest_email or user->email
|
||||
- [ ] `getClientPhone()` helper returns guest_phone or user->phone
|
||||
- [ ] Model validation ensures either user_id OR guest fields are present
|
||||
- [ ] `ConsultationFactory` updated with `guest()` state
|
||||
- [ ] Guest state generates fake guest_name, guest_email, guest_phone
|
||||
- [ ] Guest state sets user_id to null
|
||||
@@ -0,0 +1,45 @@
|
||||
---
|
||||
id: 11-2
|
||||
title: 11-2 Public Booking Form with Custom Captcha
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 11
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor, I want to request a consultation without creating an account, So that I can easily reach out to the lawyer for legal assistance. Full implementation history: docs/stories/story-11.2-public-booking-form.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] `/booking` route displays guest booking form for unauthenticated visitors
|
||||
- [ ] Logged-in users redirected to `/client/consultations/book`
|
||||
- [ ] Page uses public layout (`x-layouts.public`)
|
||||
- [ ] Bilingual support (Arabic/English)
|
||||
- [ ] Mobile responsive design
|
||||
- [ ] Reuses existing `availability-calendar` Livewire component
|
||||
- [ ] Shows available time slots (same as client view)
|
||||
- [ ] Blocked/booked times not selectable
|
||||
- [ ] Full name field (required, min 3 chars, max 255)
|
||||
- [ ] Email field (required, valid email format)
|
||||
- [ ] Phone field (required, valid format)
|
||||
- [ ] Problem summary field (required, min 20 chars, max 2000)
|
||||
- [ ] All fields have clear labels and validation messages
|
||||
- [ ] Form follows Flux UI patterns
|
||||
- [ ] Math-based captcha (e.g., "What is 7 + 3?")
|
||||
- [ ] Question generated server-side, answer stored in session
|
||||
- [ ] User must enter correct answer to submit
|
||||
- [ ] Refresh button to get new captcha question
|
||||
- [ ] Captcha validates before form submission
|
||||
- [ ] Bilingual captcha labels
|
||||
- [ ] Check if email has pending/approved booking for selected date
|
||||
- [ ] If limit reached, show error message and prevent submission
|
||||
- [ ] Clear error message explaining the limit
|
||||
- [ ] Limit applies per email address per calendar day
|
||||
- [ ] Maximum 5 booking attempts per IP per 24 hours
|
||||
- [ ] Rate limit error shown if exceeded
|
||||
- [ ] Step 1: Select date/time from calendar
|
||||
- [ ] Step 2: Fill contact info + problem summary + captcha
|
||||
- [ ] Step 3: Confirmation screen showing all details
|
||||
- [ ] Step 4: Submit creates guest consultation (status: pending)
|
||||
- [ ] Success message with instructions to check email
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 11-3
|
||||
title: 11-3 Guest Email Notifications & Admin Integration
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 11
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a guest who submitted a booking, I want to receive email confirmations about my booking status, So that I know my request was received and can track its progress. As an admin, I want to see guest contact information when reviewing bookings, So that I can contact them and manage their appointments. Full implementation history: docs/stories/story-11.3-guest-notifications-admin.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Guest receives confirmation email when booking submitted
|
||||
- [ ] Guest receives approval email when booking approved (with date/time details)
|
||||
- [ ] Guest receives rejection email when booking rejected
|
||||
- [ ] All emails use existing email template/branding
|
||||
- [ ] Emails sent to guest_email address
|
||||
- [ ] Bilingual support based on site locale at submission time
|
||||
- [ ] Guest bookings appear in pending list alongside client bookings
|
||||
- [ ] Guest bookings show "Guest" badge/indicator
|
||||
- [ ] Guest name, email, phone displayed in list
|
||||
- [ ] Click through to booking review shows full guest details
|
||||
- [ ] Guest contact info displayed prominently
|
||||
- [ ] Guest name shown instead of user name
|
||||
- [ ] Guest email shown with mailto link
|
||||
- [ ] Guest phone shown with tel link
|
||||
- [ ] Approve/reject workflow works for guest bookings
|
||||
- [ ] Email notifications sent to guest on status change
|
||||
- [ ] `NewBookingAdminEmail` updated to handle guest bookings
|
||||
- [ ] Admin email shows guest contact info for guest bookings
|
||||
- [ ] Admin email shows client info for client bookings
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: 11-4
|
||||
title: 11-4 Documentation Updates
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 11
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer or stakeholder, I want documentation to accurately reflect guest booking functionality, So that future development and maintenance has accurate reference material. Full implementation history: docs/stories/story-11.4-documentation-updates.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Section 5.4 (Booking & Consultation System) updated with guest booking flow
|
||||
- [ ] Guest vs client booking distinction documented
|
||||
- [ ] 1-per-day limit for guests documented
|
||||
- [ ] Custom captcha requirement documented
|
||||
- [ ] Rate limiting rules documented
|
||||
- [ ] Guest data handling documented
|
||||
- [ ] Database schema section updated with guest fields
|
||||
- [ ] Change log entry added
|
||||
- [ ] CaptchaService documented in Services section
|
||||
- [ ] Guest booking flow documented
|
||||
- [ ] Database schema changes noted
|
||||
- [ ] Any new patterns or services mentioned if needed
|
||||
- [ ] Epic 11 marked as complete
|
||||
- [ ] All story checkboxes marked done
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: 11
|
||||
title: 11 Guest Booking
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Extends the booking system to unauthenticated visitors: a public `/booking` form with custom (non-third-party) captcha and a 1-per-day-by-email limit, guest-specific email notifications, and admin visibility/handling of guest requests inside the existing booking review workflow, via new database schema/model support for nullable `user_id`.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All stories completed with acceptance criteria met
|
||||
- [ ] Existing client booking tests still pass
|
||||
- [ ] New tests cover guest booking scenarios
|
||||
- [ ] Admin can manage guest bookings through existing interface
|
||||
- [ ] Guest receives appropriate email notifications
|
||||
- [ ] Custom captcha working correctly
|
||||
- [ ] 1-per-day limit enforced
|
||||
- [ ] No regression in existing features
|
||||
- [ ] Bilingual support (Arabic/English) for guest form and emails
|
||||
- [ ] PRD and documentation updated
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: 12-1
|
||||
title: 12-1 Logo Asset Deployment and CSS Layout Updates
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to deploy the new square logo with Palestinian tatreez patterns and update CSS layouts So that the application displays the new brand identity correctly throughout the website. **Components:** - resources/views/components/navigation.blade.php - resources/views/components/footer.blade.php - resources/views/components/logo.blade.php - resources/views/components/app-logo.blade.php - resources/views/components/app-logo-icon.blade.php. Full implementation history: docs/stories/story-12.1-logo-asset-deployment.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Logo Files Deployed to Public Directory: Given logo files have been generated in the `logo/` folder; When I deploy them to the public directory; Then the following files are placed correctly:
|
||||
- [ ] AC2: Navigation Component Updated for Square Logo: Given the navigation uses a horizontal logo layout; When I update `resources/views/components/navigation.blade.php`; Then the following changes are applied:
|
||||
- [ ] AC3: Footer Component Updated for Square Logo: Given the footer uses the logo; When I update `resources/views/components/footer.blade.php`; Then the following changes are applied:
|
||||
- [ ] AC4: Logo Blade Component Updated: Given `resources/views/components/logo.blade.php` references logo files; When I update the component; Then it:
|
||||
- [ ] AC5: Auth Pages Logo Updated: Given auth pages (login, password reset, etc.) display the logo; When I update auth page layouts; Then the square logo displays correctly:
|
||||
- [ ] AC6: Favicon Displays in Browser Tab: Given the new favicon files are deployed; When I view the application in a browser; Then the botanical design icon appears in:
|
||||
- [ ] AC7: Mobile App Icons Updated: Given mobile manifest files reference app icons; When I update `public/manifest.json` (if exists) or meta tags; Then mobile icons reference the new files:
|
||||
- [ ] AC8: Logo Displays Correctly on All Breakpoints: Given the application is responsive; When I test the logo on different screen sizes; Then it displays correctly:
|
||||
- [ ] AC9: RTL Layout Support: Given the application supports RTL (Arabic); When viewing in Arabic mode; Then the logo displays correctly without mirroring
|
||||
- [ ] AC10: Old Logo Files Removed: Given old SVG logo files exist; When deployment is complete; Then the following old files are removed or archived:
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: 12-2
|
||||
title: 12-2 Core CSS Theme Update - Dark Charcoal & Warm Gold Palette
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update the Tailwind CSS theme to use the new dark charcoal and warm gold color palette So that the application reflects the refined LIBRA for Rights brand colors. - resources/css/app.css - Main theme file. Full implementation history: docs/stories/story-12.2-core-css-theme-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Update Color Variables in `resources/css/app.css`: Given the current theme uses Olive Green palette; When I update the `@theme` block; Then the following color mappings are applied:
|
||||
- [ ] AC2: Add Color Variants for UI States: Given the new palette needs hover and active states; When I update the theme; Then these additional variants are defined:
|
||||
- [ ] AC3: Update Button Styles: Given button classes use the primary/accent colors; When theme is updated; Then `.btn-primary` and `.btn-secondary` use new palette:
|
||||
- [ ] AC4: Update Form Focus States: Given form inputs have focus rings; When theme is updated; Then focus states use Warm Gold:
|
||||
- [ ] AC5: Update Link Colors: Given links use accent colors; When theme is updated; Then link colors use warm gold:
|
||||
- [ ] AC6: Status Colors Unchanged: Given status colors serve functional purposes; When theme is updated; Then these remain unchanged:
|
||||
- [ ] AC7: WCAG AA Contrast Compliance: Given accessibility requirements; When new colors are applied; Then all text/background combinations meet WCAG AA:
|
||||
- [ ] AC8: Update Prose Class: Given `.prose-brand` class exists for blog content; When theme is updated; Then prose colors use new palette:
|
||||
- [ ] AC9: Build Succeeds: Given CSS changes are made; When I run `npm run build`; Then the build completes successfully without errors
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: 12-3
|
||||
title: 12-3 Blade Component Color Migration - Dark Charcoal & Warm Gold
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update all Blade components and pages to use the new dark charcoal and warm gold palette So that the entire application has consistent branding. Full implementation history: docs/stories/story-12.3-blade-component-color-migration.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Navigation Component Updated: Given `resources/views/components/navigation.blade.php` uses current colors; When I update the component; Then the following changes are applied:
|
||||
- [ ] AC2: Footer Component Updated: Given `resources/views/components/footer.blade.php` uses current colors; When I update the component; Then the following changes are applied:
|
||||
- [ ] AC3: Card Components Updated: Given card components use accent colors; When I update `resources/views/components/ui/card.blade.php`; Then the following changes are applied:
|
||||
- [ ] AC4: Stat Card Component Updated: Given `resources/views/components/ui/stat-card.blade.php` uses colors; When I update the component; Then accent colors use new palette:
|
||||
- [ ] AC5: Spinner Component Updated: Given `resources/views/components/spinner.blade.php` uses colors; When I update the component; Then spinner uses Warm Gold (`#A68966`)
|
||||
- [ ] AC6: Toast Component Updated: Given `resources/views/components/toast.blade.php` uses colors; When I update the component; Then default/info toast uses Warm Gold (status colors remain unchanged)
|
||||
- [ ] AC7: Language Toggle Updated: Given `resources/views/components/language-toggle.blade.php` uses colors; When I update the component; Then :
|
||||
- [ ] AC8: Public Pages Updated: Given public pages use accent colors; When I update the following pages; Then they use the new palette:
|
||||
- [ ] AC9: Post Pages Updated: Given post display pages use colors; When I update the following pages; Then they use the new palette:
|
||||
- [ ] AC10: Admin Dashboard Components Updated: Given admin dashboard uses accent colors; When I update admin components; Then they use new palette:
|
||||
- [ ] AC11: Client Dashboard Components Updated: Given client dashboard uses accent colors; When I update client components; Then they use new palette consistently
|
||||
- [ ] AC12: Public Layout Updated: Given `resources/views/components/layouts/public.blade.php` uses colors; When I update the layout; Then it uses the new palette:
|
||||
- [ ] AC13: RTL Layout Integrity: Given the application supports RTL (Arabic); When colors are updated; Then RTL layout displays correctly with new colors
|
||||
- [ ] AC14: Responsive Appearance: Given the application is responsive; When colors are updated; Then all breakpoints display correctly (mobile, tablet, desktop)
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 12-4
|
||||
title: 12-4 Email Template Color Update - Dark Charcoal & Warm Gold
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update email templates to use the new dark charcoal and warm gold colors So that all email communications reflect the refined LIBRA for Rights branding. **Theme CSS:** - resources/views/vendor/mail/html/themes/default.css. Full implementation history: docs/stories/story-12.4-email-template-color-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Email Theme CSS Updated: Given `resources/views/vendor/mail/html/themes/default.css` uses current colors; When I update the stylesheet; Then the following changes are applied:
|
||||
- [ ] AC2: Email Header Component Updated: Given `resources/views/vendor/mail/html/header.blade.php` has inline styles; When I update the component; Then :
|
||||
- [ ] AC3: Email Footer Component Updated: Given `resources/views/vendor/mail/html/footer.blade.php` has inline styles; When I update the component; Then any inline color references use new palette:
|
||||
- [ ] AC4: Button Component Updated: Given `resources/views/vendor/mail/html/button.blade.php` may have inline styles; When I update the component; Then primary buttons use:
|
||||
- [ ] AC5: Panel Component Updated: Given `resources/views/vendor/mail/html/panel.blade.php` may have inline styles; When I update the component; Then panel border uses Gold Light (`#C4A882`)
|
||||
- [ ] AC6: All Email Templates Tested: Given the application sends various email types; When I test each email template; Then colors display correctly:
|
||||
- [ ] AC7: Plain Text Fallback Unaffected: Given plain text email templates exist; When colors are updated; Then plain text templates continue to work (no color changes needed)
|
||||
- [ ] AC8: Email Client Compatibility: Given emails are viewed in various clients; When I test the templates; Then they render correctly in:
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 12-5
|
||||
title: 12-5 PDF Template Color Update - Dark Charcoal & Warm Gold
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update PDF export templates to use the new dark charcoal and warm gold colors So that all exported documents reflect the refined LIBRA for Rights branding. **PDF Templates:** - resources/views/pdf/users-export.blade.php - resources/views/pdf/consultations-export.blade.php - resources/views/pdf/timelines-export.blade.php - resources/views/pdf/monthly-report.blade.php. Full implementation history: docs/stories/story-12.5-pdf-template-color-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Users Export PDF Updated: Given `resources/views/pdf/users-export.blade.php` uses current colors; When I update the template; Then the following changes are applied:
|
||||
- [ ] AC2: Consultations Export PDF Updated: Given `resources/views/pdf/consultations-export.blade.php` uses current colors; When I update the template; Then colors match the new palette:
|
||||
- [ ] AC3: Timelines Export PDF Updated: Given `resources/views/pdf/timelines-export.blade.php` uses current colors; When I update the template; Then colors match the new palette:
|
||||
- [ ] AC4: Monthly Report PDF Updated: Given `resources/views/pdf/monthly-report.blade.php` uses current colors; When I update the template; Then the following changes are applied:
|
||||
- [ ] AC5: Monthly Report Service Updated: Given `app/Services/MonthlyReportService.php` contains color references for charts; When I update the service; Then chart colors use new palette:
|
||||
- [ ] AC6: Print-Friendly Colors: Given PDFs are often printed; When colors are updated; Then they remain legible when printed:
|
||||
- [ ] AC7: All PDF Exports Tested: Given the admin can export various data types; When I test each PDF export; Then colors display correctly and documents are professional:
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 12-6
|
||||
title: 12-6 Brand Documentation Update - Dark Charcoal & Warm Gold
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 12
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer I want to update all brand documentation to reflect the new dark charcoal and warm gold color palette So that documentation accurately represents the current brand identity. **Documentation:** - docs/brand.md - Primary brand documentation - CLAUDE.md - Project instructions - docs/architecture.md - Architecture documentation - docs/prd.md - Product requirements. Full implementation history: docs/stories/story-12.6-documentation-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Update `docs/brand.md`: Given the brand documentation references old colors; When I update the file; Then the following sections are updated:
|
||||
- [ ] AC2: Update `CLAUDE.md`: Given CLAUDE.md contains design requirements with old colors; When I update the file; Then the Design Requirements section reflects new palette:
|
||||
- [ ] AC3: Update `docs/architecture.md` (if applicable): Given architecture docs may reference brand colors; When I review the file; Then any color references are updated to new palette
|
||||
- [ ] AC4: Update `docs/prd.md` (if applicable): Given PRD may reference brand colors; When I review the file; Then any color references are updated to new palette
|
||||
- [ ] AC5: Update Test Color Assertions: Given tests may assert specific color values; When I review test files; Then color assertions are updated:
|
||||
- [ ] AC6: Review and Update Code Comments: Given code comments may reference old color names; When I review key files; Then comments are updated:
|
||||
- [ ] AC7: Update Logo Generation Instructions (if exists): Given `docs/logo-generation-instructions.md` may exist; When I review the file; Then any color references match new palette
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id: 12
|
||||
title: 12 Branding Refresh (Logo + Color Scheme)
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Rolls out the new square LIBRA logo with Palestinian tatreez patterns and a Dark Forest Green + Warm Gold color scheme: logo asset deployment, core CSS theme update, Blade component and email/PDF template color migration, and brand documentation updates. This is the palette that `docs/brand.md` documents as current.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All stories completed with acceptance criteria met
|
||||
- [ ] New logo displays correctly across all pages and devices
|
||||
- [ ] Color scheme is consistent throughout the application
|
||||
- [ ] Brand documentation is updated
|
||||
- [ ] No regression in existing features
|
||||
- [ ] Visual QA completed on major pages
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id: 13-1
|
||||
title: 13-1 Language Toggle Visibility Enhancement
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 13
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a user on authentication pages I want to clearly see and interact with the language toggle So that I can easily switch between Arabic and English. - resources/views/components/language-toggle.blade.php. Full implementation history: docs/stories/story-13.1-language-toggle-visibility.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Update Light Variant Text Color: Given the language toggle has a `light` variant for light backgrounds; When viewed on auth pages (white/cream background); Then the inactive language uses `text-primary` (Dark Forest Green #2D3624) instead of `text-body/70`
|
||||
- [ ] AC2: Update Light Variant Hover State: Given the user hovers over an inactive language option; When the variant is `light`; Then the hover state uses:
|
||||
- [ ] AC3: Update Light Variant Separator Color: Given the separator `|` between languages; When the variant is `light`; Then it uses `text-primary/50` instead of `text-body/30` for better visibility
|
||||
- [ ] AC4: Dark Variant Unchanged: Given the language toggle has a `dark` variant for dark backgrounds (navigation bar); When viewed on the public navigation; Then the existing styling remains unchanged:
|
||||
- [ ] AC5: Active State Unchanged: Given the currently active language; When displayed in either variant; Then it maintains the existing active styling:
|
||||
- [ ] AC6: Contrast Compliance: Given accessibility requirements; When the light variant is used on Warm Cream background (#F4F1EA); Then the text contrast meets WCAG AA:
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 13-2
|
||||
title: 13-2 Auth Layout Split Design Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 13
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a visitor to the authentication pages I want to see a visually appealing split-screen layout with the LIBRA branding So that the login experience feels professional and aligned with the brand identity. - resources/views/components/layouts/auth/split.blade.php. Full implementation history: docs/stories/story-13.2-auth-split-layout.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Left Panel - Brand Side (Desktop): Given the split layout is viewed on desktop (lg+ breakpoint); When the page loads; Then the left panel displays:
|
||||
- [ ] AC2: Right Panel - Form Side (Desktop): Given the split layout is viewed on desktop; When the page loads; Then the right panel displays:
|
||||
- [ ] AC3: Mobile Layout: Given the split layout is viewed on mobile (below lg breakpoint); When the page loads; Then :
|
||||
- [ ] AC4: RTL (Arabic) Support: Given the user's locale is Arabic; When the split layout renders; Then :
|
||||
- [ ] AC5: Language Toggle Positioning: Given the language toggle component; When displayed on the split layout; Then :
|
||||
- [ ] AC6: Remove Inspiring Quotes: Given the existing split layout has inspiring quotes; When the layout is updated; Then the quotes section is removed for a cleaner, branded appearance
|
||||
- [ ] AC7: Responsive Breakpoints: Given various screen sizes; When the layout responds; Then :
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id: 13-3
|
||||
title: 13-3 Subtle Background Pattern Implementation
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 13
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a visitor to the authentication pages I want to see a subtle, elegant background pattern on the form side So that the page feels polished and professionally designed. **Option A: Geometric (Recommended)** - Simple diagonal lines or dots - Clean, modern aesthetic - Easier to create and maintain. Full implementation history: docs/stories/story-13.3-background-pattern.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Create SVG Pattern Asset: Given the need for a subtle background pattern; When the pattern is created; Then :
|
||||
- [ ] AC2: Pattern Placement: Given the SVG pattern is created; When applied to the auth layout; Then :
|
||||
- [ ] AC3: Pattern Opacity: Given readability requirements; When the pattern is displayed; Then :
|
||||
- [ ] AC4: CSS Implementation: Given the pattern asset; When integrated into CSS; Then :
|
||||
- [ ] AC5: Performance Consideration: Given page load performance; When the pattern loads; Then :
|
||||
- [ ] AC6: Mobile Compatibility: Given mobile viewport; When pattern is displayed; Then :
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: 13-4
|
||||
title: 13-4 Auth Pages Migration to Split Layout
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 13
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a user accessing any authentication page I want to see the consistent, branded split layout So that all auth pages provide a cohesive, professional experience. Full implementation history: docs/stories/story-13.4-auth-pages-migration.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Login Page Migration: Given the login page at `/login`; When the page loads; Then :
|
||||
- [ ] AC2: Forgot Password Page Migration: Given the forgot password page at `/forgot-password`; When the page loads; Then :
|
||||
- [ ] AC3: Reset Password Page Migration: Given the reset password page at `/reset-password/{token}`; When the page loads; Then :
|
||||
- [ ] AC4: Two-Factor Challenge Page Migration: Given the 2FA challenge page at `/two-factor-challenge`; When the page loads; Then :
|
||||
- [ ] AC5: Confirm Password Page Migration: Given the confirm password page at `/confirm-password`; When the page loads; Then :
|
||||
- [ ] AC6: Email Verification Page Migration: Given the email verification page at `/email/verify`; When the page loads; Then :
|
||||
- [ ] AC7: Update Default Auth Layout: Given the auth layout wrapper (`x-layouts.auth`); When called by auth pages; Then :
|
||||
- [ ] AC8: RTL Support Verified: Given Arabic language selected; When any auth page loads; Then :
|
||||
- [ ] AC9: Mobile Responsiveness Verified: Given mobile viewport (below lg breakpoint); When any auth page loads; Then :
|
||||
- [ ] AC10: Accessibility Maintained: Given accessibility requirements; When auth pages render; Then :
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: 13-5
|
||||
title: 13-5 Visual QA and Refinement
|
||||
status: Draft
|
||||
date: 2026-09-27
|
||||
parent: 13
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a product owner I want to ensure all auth pages look polished and consistent So that users have a professional, trustworthy experience. Full implementation history: docs/stories/story-13.5-visual-qa.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Cross-Browser Testing: Given the updated auth pages; When tested in major browsers; Then all pages render correctly in:
|
||||
- [ ] AC2: Desktop Viewport Testing: Given desktop viewports; When auth pages are viewed; Then the split layout displays correctly at:
|
||||
- [ ] AC3: Mobile Viewport Testing: Given mobile viewports; When auth pages are viewed; Then the mobile layout displays correctly at:
|
||||
- [ ] AC4: RTL Visual Verification: Given Arabic language selected; When all auth pages are viewed; Then :
|
||||
- [ ] AC5: Logo Visibility Verification: Given the LIBRA logo on the brand panel; When viewed on desktop; Then :
|
||||
- [ ] AC6: Language Toggle Visibility Verification: Given the language toggle on auth pages; When viewed; Then :
|
||||
- [ ] AC7: Pattern Subtlety Verification: Given the background pattern; When viewed across all pages; Then :
|
||||
- [ ] AC8: Form Element Alignment: Given form elements on auth pages; When viewed; Then :
|
||||
- [ ] AC9: Color Consistency: Given the brand color palette; When auth pages are viewed; Then :
|
||||
- [ ] AC10: Animation/Transition Polish: Given interactive elements; When interacted with; Then :
|
||||
- [ ] AC11: Print Stylesheet (Optional): Given a user prints an auth page; When the page is printed; Then :
|
||||
- [ ] AC12: Fix Any Visual Issues: Given issues discovered during QA; When fixes are needed; Then :
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 13
|
||||
title: 13 Authentication Pages Design Enhancement
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Redesigns the auth pages (login, forgot/reset password, etc.) from plain layouts into a branded split-screen experience — dark panel with the LIBRA logo on one side, a warm-cream form panel with a subtle background pattern on the other — plus a language-toggle visibility fix, migration of all auth pages to the new layout, and a final cross-browser/viewport visual QA pass.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All stories completed with acceptance criteria met
|
||||
- [ ] Language toggle visible and accessible on auth pages
|
||||
- [ ] Split layout displays correctly on desktop and tablet
|
||||
- [ ] Mobile layout is functional and attractive
|
||||
- [ ] RTL (Arabic) layout mirrors correctly
|
||||
- [ ] Pattern is subtle and professional
|
||||
- [ ] No regression in auth functionality
|
||||
- [ ] Visual QA completed on major browsers (Chrome, Firefox, Safari)
|
||||
- [ ] Accessibility audit passed (contrast ratios, focus states)
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 14-1
|
||||
title: 14-1 Hero Section Implementation
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see an impactful hero section when I land on the home page So that I immediately understand what Libra offers and how to take action. - resources/views/pages/home.blade.php - Main implementation - lang/en/home.php - English translations - lang/ar/home.php - Arabic translations. Full implementation history: docs/stories/story-14.1-hero-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Hero Section Container: Given a visitor lands on the home page; When the page loads; Then a full-width hero section is displayed with:
|
||||
- [ ] AC2: Tagline Display: Given the hero section; When viewed in English; Then display: "Committed to Justice – Grounded in Dignity – Driven to Advocate"
|
||||
- [ ] AC3: Introductory Text: Given the hero section below the tagline; When displayed; Then show a brief 1-2 sentence introduction:
|
||||
- [ ] AC4: Primary CTA Button: Given the hero section; When displayed below the intro text; Then show a primary CTA button:
|
||||
- [ ] AC5: Secondary CTA Button (Optional): Given the hero section; When displayed next to primary CTA; Then show a secondary CTA button:
|
||||
- [ ] AC6: Responsive Layout: Given different screen sizes; When viewing the hero section:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the hero section; Then all text and elements align right-to-left correctly
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 14-2
|
||||
title: 14-2 About Section with Lawyer Profile
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see information about the lawyer behind Libra So that I can trust the firm and understand who will be handling my case. - resources/views/pages/home.blade.php - Add about section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations - public/images/huda-armouche.jpg - Lawyer photo (to be added). Full implementation history: docs/stories/story-14.2-about-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Section Container: Given a visitor scrolls past the hero section; When viewing the about section; Then display a section with:
|
||||
- [ ] AC2: Section Heading: Given the about section; When displayed; Then show a section heading:
|
||||
- [ ] AC3: Lawyer Photo: Given the about section; When displayed; Then show Huda Armouche's professional photo:
|
||||
- [ ] AC4: Lawyer Name and Title: Given the about section; When displayed; Then show:
|
||||
- [ ] AC5: Bio Text: Given the about section; When displayed; Then show a professional bio:
|
||||
- [ ] AC6: Layout Structure: Given different screen sizes; When viewing the about section:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the about section; Then layout mirrors appropriately (photo on right in RTL if it was on left in LTR)
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 14-3
|
||||
title: 14-3 Services Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see what legal services Libra offers So that I can determine if they can help with my legal needs. - resources/views/pages/home.blade.php - Add services section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.3-services-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Section Container: Given a visitor scrolls to the services section; When viewing the section; Then display with:
|
||||
- [ ] AC2: Section Heading: Given the services section; When displayed; Then show a section heading:
|
||||
- [ ] AC3: Four Service Cards: Given the services section; When displayed; Then show 4 service cards:
|
||||
- [ ] AC4: Service Card Design: Given each service card; When displayed; Then include:
|
||||
- [ ] AC5: Service Descriptions: Given each service card; When displayed; Then show appropriate descriptions:
|
||||
- [ ] AC6: Grid Layout: Given different screen sizes; When viewing the services section:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the services section; Then cards maintain proper alignment and text direction
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 14-4
|
||||
title: 14-4 Values Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to understand Libra's core values So that I can assess if their principles align with my expectations. - resources/views/pages/home.blade.php - Add values section - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.4-values-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Section Container: Given a visitor scrolls to the values section; When viewing the section; Then display with:
|
||||
- [ ] AC2: Section Heading: Given the values section; When displayed; Then show a section heading:
|
||||
- [ ] AC3: Six Value Items: Given the values section; When displayed; Then show 6 values:
|
||||
- [ ] AC4: Value Item Design: Given each value item; When displayed; Then include:
|
||||
- [ ] AC5: Grid Layout: Given different screen sizes; When viewing the values section:
|
||||
- [ ] AC6: Visual Style Options: Given the values display; When implemented; Then choose one of these styles:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the values section; Then items maintain proper alignment and text direction
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: 14-5
|
||||
title: 14-5 Latest Posts Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see recent legal articles and updates on the home page So that I can access valuable legal content and see that the firm is active. - resources/views/pages/home.blade.php - Add posts section with data query - lang/en/home.php - Add translations - lang/ar/home.php - Add translations. Full implementation history: docs/stories/story-14.5-latest-posts-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Section Container: Given a visitor scrolls to the latest posts section; When viewing the section; Then display with:
|
||||
- [ ] AC2: Section Heading: Given the latest posts section; When displayed; Then show a section heading:
|
||||
- [ ] AC3: Display 3 Latest Posts: Given the posts section; When posts exist in the database; Then display the 3 most recent published posts showing:
|
||||
- [ ] AC4: Post Card Design: Given each post card; When displayed; Then include:
|
||||
- [ ] AC5: Empty State: Given the posts section; When no published posts exist; Then either:
|
||||
- [ ] AC6: View All Link: Given the posts section; When posts are displayed; Then show a "View All Articles" / "عرض جميع المقالات" link:
|
||||
- [ ] AC7: Grid Layout: Given different screen sizes; When viewing the posts section:
|
||||
- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the posts section; Then cards and text align right-to-left correctly
|
||||
- [ ] AC9: Dynamic Data: Given the posts section; When rendered; Then query posts from database:
|
||||
@@ -0,0 +1,20 @@
|
||||
---
|
||||
id: 14-6
|
||||
title: 14-6 Footer Contact Information Update
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 14
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see accurate contact information in the footer So that I can reach out to Libra through the correct phone number and address. - resources/views/components/layouts/public.blade.php - Main footer location - OR resources/views/components/footer.blade.php - If footer is a separate component. Full implementation history: docs/stories/story-14.6-footer-update.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Update Phone Number: Given the website footer; When displayed; Then show the phone number: `+970599353502`
|
||||
- [ ] AC2: Update Address: Given the website footer; When displayed; Then show the address:
|
||||
- [ ] AC3: Phone Display Format: Given the phone number in footer; When displayed; Then format as:
|
||||
- [ ] AC4: Contact Section Layout: Given the footer contact area; When displayed; Then include:
|
||||
- [ ] AC5: RTL Support: Given Arabic language is selected; When viewing the footer; Then address displays in Arabic and layout adjusts for RTL
|
||||
- [ ] AC6: Consistency Check: Given the footer update; When completed; Then ensure footer displays correctly on:
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: 14
|
||||
title: 14 Home Page Redesign
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Transforms the minimal home page into a full landing page: hero section, an about section featuring lawyer Huda Armouche, a services section, a values section, a latest-posts section pulling live data, and an updated footer with current contact information.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All 6 stories completed with acceptance criteria met
|
||||
- [ ] Hero section displays tagline and CTAs correctly
|
||||
- [ ] About section shows lawyer photo and bio
|
||||
- [ ] Services section displays 4 generalized services
|
||||
- [ ] Values section displays 6 values with icons
|
||||
- [ ] Latest posts section pulls real data from database
|
||||
- [ ] Footer shows updated phone and address
|
||||
- [ ] Responsive design works on mobile, tablet, desktop
|
||||
- [ ] RTL (Arabic) layout displays correctly
|
||||
- [ ] LTR (English) layout displays correctly
|
||||
- [ ] All text in translation files (ar/en)
|
||||
- [ ] Visual consistency with brand guidelines
|
||||
- [ ] Accessibility standards maintained
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id: 15-1
|
||||
title: 15-1 Database Schema & Model Setup
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 15
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin I want to have a database structure for potential clients So that I can store and manage prospective client information. Full implementation history: docs/stories/story-15.1-database-model.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Database Migration: Given the system needs to store potential clients; When the migration runs; Then a `potential_clients` table is created with:
|
||||
- [ ] AC2: PotentialClientType Enum: Given potential clients have different types; When the enum is created; Then `App\Enums\PotentialClientType` contains:
|
||||
- [ ] AC3: PotentialClient Model: Given the migration exists; When the model is created; Then `App\Models\PotentialClient` includes:
|
||||
- [ ] AC4: Model Factory: Given tests need potential client data; When the factory is created; Then `Database\Factories\PotentialClientFactory` generates:
|
||||
- [ ] AC5: Translation Keys: Given the system is bilingual; When translations are added; Then create keys in `lang/en/potential-clients.php` and `lang/ar/potential-clients.php`:
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: 15-2
|
||||
title: 15-2 Potential Clients List with Type Filter
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 15
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin I want to view a list of potential clients with filtering capabilities So that I can easily browse and find specific prospective clients. | File | Purpose | |------|---------| | resources/views/livewire/admin/potential-clients/index.blade.php | List Volt component | | routes/web.php | Add route for potential clients |. Full implementation history: docs/stories/story-15.2-list-filter.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Admin Navigation: Given the admin is logged in; When viewing the admin sidebar; Then a "Potential Clients" menu item is visible with an appropriate icon
|
||||
- [ ] AC2: List Page Header: Given the admin navigates to `/admin/potential-clients`; When the page loads; Then display:
|
||||
- [ ] AC3: Type Filter: Given the potential clients list; When the filter is displayed; Then a type dropdown includes:
|
||||
- [ ] AC4: Search Functionality: Given the potential clients list; When the admin types in the search box; Then filter potential clients by name, email, or phone
|
||||
- [ ] AC5: List Table Display: Given potential clients exist; When viewing the list; Then display a table with columns:
|
||||
- [ ] AC6: Type Badges: Given potential clients in the list; When displaying the type; Then show colored badges:
|
||||
- [ ] AC7: Empty State: Given no potential clients exist; When viewing the list; Then display an empty state with:
|
||||
- [ ] AC8: Pagination: Given more than 10 potential clients exist; When viewing the list; Then display pagination controls
|
||||
- [ ] AC9: Clear Filters: Given search or type filter is active; When admin clicks "Clear filters"; Then reset all filters to defaults
|
||||
- [ ] AC10: RTL Support: Given Arabic language is selected; When viewing the potential clients list; Then all text and layout align correctly right-to-left
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: 15-3
|
||||
title: 15-3 CRUD Operations for Potential Clients
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 15
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin I want to create, view, edit, and delete potential clients So that I can fully manage my prospective client records. | File | Purpose | |------|---------| | resources/views/livewire/admin/potential-clients/create.blade.php | Create form component | | resources/views/livewire/admin/potential-clients/show.blade.php | View page component | | resources/views/livewire/admin/potential-clients/edit.blade.php | Edit form component |. Full implementation history: docs/stories/story-15.3-crud-operations.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Create Form Access: Given the admin is on the potential clients list; When clicking "Add Potential Client"; Then navigate to `/admin/potential-clients/create`
|
||||
- [ ] AC2: Create Form Fields: Given the admin is on the create form; When the form is displayed; Then show the following fields:
|
||||
- [ ] AC3: Create Submission: Given the admin fills the create form; When submitting with valid data; Then create a new potential client record
|
||||
- [ ] AC4: Create Validation: Given the admin submits the create form; When type is not selected; Then show validation error: "Please select a type" / "يرجى اختيار النوع"
|
||||
- [ ] AC5: View Page: Given a potential client exists; When the admin clicks the view icon from the list; Then navigate to `/admin/potential-clients/{id}`
|
||||
- [ ] AC6: View Page Display: Given the admin is viewing a potential client; When the page loads; Then display:
|
||||
- [ ] AC7: Edit Form Access: Given the admin is viewing a potential client; When clicking "Edit"; Then navigate to `/admin/potential-clients/{id}/edit`
|
||||
- [ ] AC8: Edit Form Submission: Given the admin modifies the edit form; When submitting with valid data; Then update the potential client record
|
||||
- [ ] AC9: Delete Confirmation: Given the admin is viewing a potential client; When clicking "Delete"; Then show a confirmation modal with:
|
||||
- [ ] AC10: Delete Execution: Given the delete confirmation modal is shown; When the admin confirms deletion; Then delete the potential client record
|
||||
- [ ] AC11: RTL Support: Given Arabic language is selected; When viewing create/edit/view pages; Then all forms and layouts align correctly right-to-left
|
||||
- [ ] AC12: Cancel Actions: Given the admin is on create or edit form; When clicking "Cancel"; Then navigate back to the previous page (list or view)
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id: 15
|
||||
title: 15 Potential Clients Management
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Adds an admin-only lead-tracking system for prospects (individual/company/agency) who don't yet have accounts: a new standalone `PotentialClient` model/table, a filterable list view by client type, and full CRUD, following existing admin interface patterns.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All stories completed with acceptance criteria met
|
||||
- [ ] Tests cover CRUD operations and filtering
|
||||
- [ ] Admin can manage potential clients through new interface
|
||||
- [ ] No regression in existing features
|
||||
- [ ] Bilingual support (Arabic/English) for all UI elements
|
||||
- [ ] Admin navigation updated with new menu item
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 16-1
|
||||
title: 16-1 About Page Layout & Hero Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to access a dedicated About Us page So that I can learn about Libra for Rights' identity and purpose. - resources/views/pages/about.blade.php - Main page - lang/en/about.php - English translations - lang/ar/about.php - Arabic translations. Full implementation history: docs/stories/story-16.1-about-page-layout-hero.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Route & Navigation: Given a visitor on any page; When they look at the main navigation; Then an "About Us" / "من نحن" link is visible
|
||||
- [ ] AC2: Page Structure: Given a visitor accesses `/about`; When the page loads; Then the page uses the public layout with:
|
||||
- [ ] AC3: Hero Section Container: Given the About Us page loads; When displayed; Then show a hero section with:
|
||||
- [ ] AC4: Page Title: Given the hero section; When viewed in English; Then display title: "About Us"
|
||||
- [ ] AC5: Tagline Display: Given the hero section below the title; When displayed; Then show the tagline:
|
||||
- [ ] AC6: Identity Statement: Given the hero section below the tagline; When displayed; Then show the identity statement:
|
||||
- [ ] AC7: Responsive Layout: Given different screen sizes; When viewing the hero section:
|
||||
- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the page; Then all text and elements align right-to-left correctly
|
||||
@@ -0,0 +1,23 @@
|
||||
---
|
||||
id: 16-2
|
||||
title: 16-2 Vision & Mission Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to read Libra's vision and mission statements So that I understand the organization's purpose and who they serve. Full implementation history: docs/stories/story-16.2-vision-mission-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Vision Section Container: Given the About Us page below the hero; When displayed; Then show a vision section with:
|
||||
- [ ] AC2: Vision Section Header: Given the vision section; When displayed; Then show section header:
|
||||
- [ ] AC3: Vision Statement: Given the vision section; When displayed; Then show the full vision statement:
|
||||
- [ ] AC4: Mission Section Container: Given the About Us page below the vision; When displayed; Then show a mission section with:
|
||||
- [ ] AC5: Mission Section Header: Given the mission section; When displayed; Then show section header:
|
||||
- [ ] AC6: Mission Cards - Three Categories: Given the mission section; When displayed; Then show 3 mission cards in a responsive grid:
|
||||
- [ ] AC7: Mission Card Styling: Given each mission card; When displayed; Then style with:
|
||||
- [ ] AC8: Responsive Grid: Given different screen sizes; When viewing mission cards:
|
||||
- [ ] AC9: RTL Support: Given Arabic language is selected; When viewing both sections; Then all text and cards align right-to-left correctly
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 16-3
|
||||
title: 16-3 Values Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see Libra's core values So that I understand the principles that guide their work. Full implementation history: docs/stories/story-16.3-values-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Values Section Container: Given the About Us page below the mission section; When displayed; Then show a values section with:
|
||||
- [ ] AC2: Values Section Header: Given the values section; When displayed; Then show section header:
|
||||
- [ ] AC3: Values Introduction: Given the values section below the header; When displayed; Then show introductory text:
|
||||
- [ ] AC4: Six Value Cards: Given the values section; When displayed; Then show 6 value cards:
|
||||
- [ ] AC5: Value Card Styling: Given each value card; When displayed; Then style with:
|
||||
- [ ] AC6: Responsive Grid: Given different screen sizes; When viewing value cards:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the values section; Then all cards and text align correctly for RTL
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 16-4
|
||||
title: 16-4 Goals Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see Libra's organizational goals So that I understand what they are working to achieve. Full implementation history: docs/stories/story-16.4-goals-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Goals Section Container: Given the About Us page below the values section; When displayed; Then show a goals section with:
|
||||
- [ ] AC2: Goals Section Header: Given the goals section; When displayed; Then show section header:
|
||||
- [ ] AC3: Seven Goals Display: Given the goals section; When displayed; Then show all 7 goals:
|
||||
- [ ] AC4: Goals List Styling: Given the goals list; When displayed; Then style as:
|
||||
- [ ] AC5: Numbered Circle Style: Given each goal number; When displayed; Then style the number with:
|
||||
- [ ] AC6: Responsive Layout: Given different screen sizes; When viewing goals:
|
||||
- [ ] AC7: RTL Support: Given Arabic language is selected; When viewing the goals section; Then numbers align on the right, text flows RTL
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 16-5
|
||||
title: 16-5 Legal Services Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to see Libra's comprehensive legal services So that I know what services they offer and if they can help with my legal needs. Full implementation history: docs/stories/story-16.5-legal-services-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Services Section Container: Given the About Us page below the goals section; When displayed; Then show a services section with:
|
||||
- [ ] AC2: Services Section Header: Given the services section; When displayed; Then show section header:
|
||||
- [ ] AC3: Services Introduction: Given the services section below the header; When displayed; Then show introductory text:
|
||||
- [ ] AC4: Four Service Categories: Given the services section; When displayed; Then show 4 service category cards:
|
||||
- [ ] AC5: Service Card Styling: Given each service card; When displayed; Then style with:
|
||||
- [ ] AC6: Responsive Grid: Given different screen sizes; When viewing service cards:
|
||||
- [ ] AC7: CTA Button: Given the services section; When displayed below the cards; Then show a CTA button:
|
||||
- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the services section; Then all cards, lists, and text align correctly for RTL
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 16-6
|
||||
title: 16-6 Scholarship Aspiration Section
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 16
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor I want to learn about Libra's scholarship aspiration So that I understand their vision for supporting Palestinian arts and law students. Full implementation history: docs/stories/story-16.6-scholarship-section.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] AC1: Scholarship Section Container: Given the About Us page below the services section; When displayed; Then show a scholarship section with:
|
||||
- [ ] AC2: Scholarship Section Header: Given the scholarship section; When displayed; Then show section header:
|
||||
- [ ] AC3: Scholarship Description: Given the scholarship section; When displayed; Then show the scholarship description with two paragraphs:
|
||||
- [ ] AC4: Key Aspirations List: Given the scholarship section below the description; When displayed; Then show 4 key aspirations as highlight items:
|
||||
- [ ] AC5: Aspiration Item Styling: Given each aspiration item; When displayed; Then style with:
|
||||
- [ ] AC6: Visual Accent: Given the scholarship section; When displayed; Then include:
|
||||
- [ ] AC7: Responsive Layout: Given different screen sizes; When viewing the scholarship section:
|
||||
- [ ] AC8: RTL Support: Given Arabic language is selected; When viewing the scholarship section; Then all text and items align correctly for RTL
|
||||
@@ -0,0 +1,28 @@
|
||||
---
|
||||
id: 16
|
||||
title: 16 About Us Page
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Builds a new public `/about` page presenting LIBRA for Rights' identity, vision, mission, values, goals, legal services, and scholarship aspiration, sourced from the organization's vision/mission/values document, across hero, vision/mission, values, goals, legal-services, and scholarship sections.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] All 6 stories completed with acceptance criteria met
|
||||
- [ ] About Us page accessible at `/about`
|
||||
- [ ] Navigation updated with About Us link
|
||||
- [ ] Hero section displays title and identity statement
|
||||
- [ ] Vision section displays full vision statement
|
||||
- [ ] Mission section displays all three mission categories
|
||||
- [ ] Values section displays 6 values with icons
|
||||
- [ ] Goals section displays 7 goals
|
||||
- [ ] Legal services section displays all service categories
|
||||
- [ ] Scholarship section displays aspiration content
|
||||
- [ ] Responsive design works on mobile, tablet, desktop
|
||||
- [ ] RTL (Arabic) layout displays correctly
|
||||
- [ ] LTR (English) layout displays correctly
|
||||
- [ ] All text in translation files (ar/en)
|
||||
- [ ] Visual consistency with brand guidelines
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: 2-1
|
||||
title: 2-1 Individual Client Account Management
|
||||
status: Done
|
||||
date: 2026-09-27
|
||||
parent: 2
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to create, view, edit, and search individual client accounts, So that I can manage client information and provide them platform access. Context: Integrates with: Users table, Fortify authentication; Technology: Livewire Volt, Flux UI forms; Follows pattern: Admin CRUD patterns, class-based Volt components. - **Validation failure:** Display inline field errors using Flux UI error states - **Duplicate email:** Show "Email already exists" error on email field - **Duplicate National ID:** Show "National ID already registered" error - **Empty search results:** Display "No clients found" message with clear filters option. Full implementation history: docs/stories/story-2.1-individual-client-account-management.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Form with required fields:
|
||||
- [ ] Validation for all required fields
|
||||
- [ ] Duplicate email/National ID prevention with clear error message
|
||||
- [ ] Password strength indicator (optional)
|
||||
- [ ] Success message on creation
|
||||
- [ ] Display all individual clients (user_type = 'individual')
|
||||
- [ ] Columns: Name, Email, National ID, Phone, Status, Created Date
|
||||
- [ ] Pagination (10/25/50 per page)
|
||||
- [ ] Default sort by created date (newest first)
|
||||
- [ ] Search by name, email, or National ID
|
||||
- [ ] Filter by status (active/deactivated/all)
|
||||
- [ ] Real-time search with debounce (300ms)
|
||||
- [ ] Clear filters button
|
||||
- [ ] Edit all client information
|
||||
- [ ] Cannot change user_type from this form
|
||||
- [ ] Validation same as create
|
||||
- [ ] Success message on update
|
||||
- [ ] Display all client information
|
||||
- [ ] Show consultation history summary
|
||||
- [ ] Show timeline history summary
|
||||
- [ ] Quick links to related records
|
||||
- [ ] Bilingual form labels and messages
|
||||
- [ ] Proper form validation with error display
|
||||
- [ ] Audit log entries for all operations
|
||||
- [ ] Tests for CRUD operations
|
||||
@@ -0,0 +1,36 @@
|
||||
---
|
||||
id: 2-2
|
||||
title: 2-2 Company/Corporate Client Account Management
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 2
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to create, view, edit, and manage company/corporate client accounts, So that I can serve corporate clients with their unique data requirements. Context: Integrates with: `users` table (company-specific fields), `admin_logs` table; Technology: Livewire Volt (class-based), Flux UI forms, Pest tests; Follows pattern: Same CRUD pattern as Story 2.1 Individual Clients. > **Note:** This migration is NOT part of this story. It is preserved here for future reference if multiple contact persons feature is prioritized. Full implementation history: docs/stories/story-2.2-company-client-account-management.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Form with required fields:
|
||||
- [ ] Validation for all required fields
|
||||
- [ ] Duplicate email/registration number prevention
|
||||
- [ ] Success message on creation
|
||||
- [ ] Display all company clients (user_type = 'company')
|
||||
- [ ] Columns: Company Name, Contact Person, Email, Reg #, Status, Created Date
|
||||
- [ ] Pagination (10/25/50 per page)
|
||||
- [ ] Default sort by created date
|
||||
- [ ] Search by company name, email, or registration number
|
||||
- [ ] Filter by status (active/deactivated/all)
|
||||
- [ ] Real-time search with debounce
|
||||
- [ ] Edit all company information
|
||||
- [ ] Update contact person details
|
||||
- [ ] Validation same as create
|
||||
- [ ] Success message on update
|
||||
- [ ] Display all company information (including contact person details)
|
||||
- [ ] Show consultation history summary
|
||||
- [ ] Show timeline history summary
|
||||
- [ ] Bilingual form labels and messages
|
||||
- [ ] Proper form validation
|
||||
- [ ] Audit log entries for all operations
|
||||
- [ ] Tests for CRUD operations
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 2-3
|
||||
title: 2-3 Account Type Conversion
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 2
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to convert individual accounts to company accounts and vice versa, So that I can accommodate clients whose business structure changes. Context: Integrates with: Users table, consultations, timelines; Technology: Livewire Volt (class-based), Flux UI modals, Pest tests; Follows pattern: Admin action pattern with confirmation modal (same as Story 2.1/2.2 CRUD pattern). Full implementation history: docs/stories/story-2.3-account-type-conversion.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] "Convert to Company" action available on individual profiles
|
||||
- [ ] Modal/form prompts for additional company fields:
|
||||
- [ ] Preserve existing data (email, phone, password)
|
||||
- [ ] Preserve all consultation history
|
||||
- [ ] Preserve all timeline history
|
||||
- [ ] Confirmation dialog before conversion
|
||||
- [ ] Success message after conversion
|
||||
- [ ] "Convert to Individual" action available on company profiles
|
||||
- [ ] Modal/form prompts for individual-specific fields:
|
||||
- [ ] Handle company-specific data:
|
||||
- [ ] Preserve all consultation history
|
||||
- [ ] Preserve all timeline history
|
||||
- [ ] Confirmation dialog before conversion
|
||||
- [ ] Audit log entry capturing:
|
||||
- [ ] Email notification to user about account type change
|
||||
- [ ] Bilingual confirmation dialogs
|
||||
- [ ] Bilingual email notification
|
||||
- [ ] All data preserved (verify in tests)
|
||||
- [ ] No broken relationships after conversion
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: 2-4
|
||||
title: 2-4 Account Lifecycle Management
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 2
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to deactivate, reactivate, and permanently delete client accounts, So that I can manage the full lifecycle of client relationships. Context: Integrates with: Users table, consultations, timelines, notifications, sessions; Technology: Livewire Volt (class-based), Flux UI modals, Pest tests; Follows pattern: Same admin action patterns as Story 2.1/2.2, soft deactivation via status field, hard deletion with cascade. Full implementation history: docs/stories/story-2.4-account-lifecycle-management.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] "Deactivate" button on user profile and list
|
||||
- [ ] Confirmation dialog explaining consequences
|
||||
- [ ] Effects of deactivation:
|
||||
- [ ] Visual indicator in user list (grayed out, badge)
|
||||
- [ ] Audit log entry created
|
||||
- [ ] "Reactivate" button on deactivated profiles
|
||||
- [ ] Confirmation dialog
|
||||
- [ ] Effects of reactivation:
|
||||
- [ ] Email notification sent to user
|
||||
- [ ] Audit log entry created
|
||||
- [ ] "Delete" button (with danger styling)
|
||||
- [ ] Confirmation dialog with strong warning:
|
||||
- [ ] Effects of deletion:
|
||||
- [ ] Audit log entry preserved (for audit trail)
|
||||
- [ ] No email sent (user no longer exists)
|
||||
- [ ] "Reset Password" action on user profile
|
||||
- [ ] Options:
|
||||
- [ ] Email new credentials to client
|
||||
- [ ] Force password change on next login (optional) - Not implemented per simplified approach
|
||||
- [ ] Audit log entry created
|
||||
- [ ] All actions logged in admin_logs table
|
||||
- [ ] Bilingual confirmation messages
|
||||
- [ ] Clear visual states for account status
|
||||
- [ ] Tests for all lifecycle operations
|
||||
@@ -0,0 +1,46 @@
|
||||
---
|
||||
id: 2-5
|
||||
title: 2-5 Account Creation Email Notification
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 2
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want welcome emails sent automatically when I create client accounts, So that clients receive their login credentials and know how to access the platform. Context: Integrates with: User creation flow, Laravel Mail; Technology: Laravel Mailable, queued jobs; Follows pattern: Laravel notification/mailable patterns. Full implementation history: docs/stories/story-2.5-account-creation-email-notification.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Email sent automatically on account creation
|
||||
- [ ] Works for both individual and company accounts
|
||||
- [ ] Queued for performance (async sending)
|
||||
- [ ] No email sent for admin accounts
|
||||
- [ ] Personalized greeting:
|
||||
- [ ] Message: "Your account has been created"
|
||||
- [ ] Login credentials:
|
||||
- [ ] Login URL (clickable button/link)
|
||||
- [ ] Brief platform introduction
|
||||
- [ ] Contact information for questions
|
||||
- [ ] Professional template with Libra branding
|
||||
- [ ] Colors: Navy blue (#0A1F44) and Gold (#D4AF37)
|
||||
- [ ] Libra logo in header
|
||||
- [ ] Footer with firm information
|
||||
- [ ] Mobile-responsive layout
|
||||
- [ ] From: no-reply@libra.ps
|
||||
- [ ] From Name: Libra Law Firm / مكتب ليبرا للمحاماة
|
||||
- [ ] Reply-To: (firm contact email)
|
||||
- [ ] Email in user's preferred_language
|
||||
- [ ] Arabic email for Arabic preference
|
||||
- [ ] English email for English preference
|
||||
- [ ] All text translated
|
||||
- [ ] Plain text version generated
|
||||
- [ ] All essential information included
|
||||
- [ ] Readable without HTML
|
||||
- [ ] Email passes spam filters
|
||||
- [ ] Links work correctly
|
||||
- [ ] Password visible but not overly prominent
|
||||
- [ ] Tests verify email sending
|
||||
- [ ] Email queued with retry on failure (Laravel default: 3 attempts)
|
||||
- [ ] Failed emails logged to `failed_jobs` table
|
||||
- [ ] User creation succeeds even if email fails (non-blocking)
|
||||
@@ -0,0 +1,22 @@
|
||||
---
|
||||
id: 2
|
||||
title: 2 User Management System
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Gives the admin full lifecycle control over client accounts: creating individual and company/corporate accounts, converting between types, deactivating or permanently deleting accounts, resetting passwords, and sending welcome-email notifications. All operations are audit-logged.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Admin can create individual client accounts
|
||||
- [ ] Admin can create company/corporate client accounts
|
||||
- [ ] Admin can convert between account types
|
||||
- [ ] Admin can deactivate accounts (data retained)
|
||||
- [ ] Admin can permanently delete accounts
|
||||
- [ ] Admin can reset client passwords
|
||||
- [ ] Welcome email sent with login credentials
|
||||
- [ ] User search and filtering functional
|
||||
- [ ] All operations logged for audit
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 3-1
|
||||
title: 3-1 Working Hours Configuration
|
||||
status: Done
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to configure available working hours for each day of the week, So that clients can only book consultations during my available times. Context: Integrates with: working_hours table, availability calendar; Technology: Livewire Volt, Flux UI forms; Follows pattern: Admin settings pattern. The AdminLog model is used for audit logging (defined in Epic 1). Schema:. Full implementation history: docs/stories/story-3.1-working-hours-configuration.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Set available days (enable/disable each day of week)
|
||||
- [ ] Set start time for each enabled day
|
||||
- [ ] Set end time for each enabled day
|
||||
- [ ] Support different hours for different days
|
||||
- [ ] 15-minute buffer automatically applied between appointments
|
||||
- [ ] 12-hour time format display (AM/PM)
|
||||
- [ ] Visual weekly schedule view
|
||||
- [ ] Toggle for each day (Sunday-Saturday)
|
||||
- [ ] Time pickers for start/end times
|
||||
- [ ] Preview of available slots per day
|
||||
- [ ] Save button with confirmation
|
||||
- [ ] Changes take effect immediately for new bookings
|
||||
- [ ] Existing approved bookings NOT affected by changes
|
||||
- [ ] Warning if changing hours that have pending bookings
|
||||
- [ ] Validation: end time must be after start time
|
||||
- [ ] Bilingual labels and messages
|
||||
- [ ] Default working hours on initial setup
|
||||
- [ ] Audit log entry on changes
|
||||
- [ ] Tests for configuration logic
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: 3-2
|
||||
title: 3-2 Time Slot Blocking
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to block specific dates or time ranges for personal events or holidays, So that clients cannot book during my unavailable times. Context: Integrates with: blocked_times table, availability calendar; Technology: Livewire Volt, Flux UI; Follows pattern: CRUD pattern with calendar integration. Full implementation history: docs/stories/story-3.2-time-slot-blocking.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Block entire days (all-day events)
|
||||
- [ ] Block specific time ranges within a day
|
||||
- [ ] Add reason/note for blocked time
|
||||
- [ ] View list of all blocked times (upcoming and past)
|
||||
- [ ] Edit blocked times
|
||||
- [ ] Delete blocked times
|
||||
- [ ] Select date (date picker)
|
||||
- [ ] Choose: All day OR specific time range
|
||||
- [ ] If time range: start time and end time
|
||||
- [ ] Optional reason/note field
|
||||
- [ ] Confirmation on save
|
||||
- [ ] Blocked times show as unavailable in calendar (Story 3.3 dependency)
|
||||
- [ ] Visual distinction from "already booked" slots (Story 3.3 dependency)
|
||||
- [ ] Future blocked times don't affect existing approved bookings
|
||||
- [ ] Warning if blocking time with pending bookings
|
||||
- [ ] Show all blocked times
|
||||
- [ ] Sort by date (upcoming first)
|
||||
- [ ] Filter: past/upcoming/all
|
||||
- [ ] Quick actions: edit, delete
|
||||
- [ ] Show reason if provided
|
||||
- [ ] Bilingual support
|
||||
- [ ] Audit log for create/edit/delete
|
||||
- [ ] Validation: end time after start time
|
||||
- [ ] Tests for blocking logic
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: 3-3
|
||||
title: 3-3 Availability Calendar Display
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to see a calendar with available time slots, So that I can choose a convenient time for my consultation. Context: Integrates with: working_hours, blocked_times, consultations tables; Technology: Livewire Volt, JavaScript calendar library; Follows pattern: Real-time availability checking. Full implementation history: docs/stories/story-3.3-availability-calendar-display.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Monthly calendar view showing available dates
|
||||
- [ ] Visual distinction for date states:
|
||||
- [ ] Navigate between months
|
||||
- [ ] Current month shown by default
|
||||
- [ ] Clicking a date shows available time slots
|
||||
- [ ] 1-hour slots (45min consultation + 15min buffer)
|
||||
- [ ] Clear indication of slot availability
|
||||
- [ ] Unavailable reasons (optional):
|
||||
- [ ] Availability checked on date selection
|
||||
- [ ] Prevent double-booking (race condition handling)
|
||||
- [ ] Refresh availability when navigating months
|
||||
- [ ] Prevent navigating to months before current month (all dates would be "past")
|
||||
- [ ] Optionally limit future navigation (e.g., max 3 months ahead) - configurable (deferred to future story)
|
||||
- [ ] Mobile-friendly calendar
|
||||
- [ ] Touch-friendly slot selection
|
||||
- [ ] Proper RTL support for Arabic
|
||||
- [ ] Fast loading (eager load data)
|
||||
- [ ] Language-appropriate date formatting
|
||||
- [ ] Accessible (keyboard navigation)
|
||||
- [ ] Tests for availability logic
|
||||
@@ -0,0 +1,19 @@
|
||||
---
|
||||
id: 3-4
|
||||
title: 3-4 Booking Request Submission
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to submit a consultation booking request, so that I can schedule a meeting with the lawyer. Full implementation history: docs/stories/story-3.4-booking-request-submission.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Booking Form (AC1-5)
|
||||
- [ ] Validation & Constraints (AC6-9)
|
||||
- [ ] Submission Flow (AC10-14)
|
||||
- [ ] UI/UX (AC15-18)
|
||||
- [ ] Quality Requirements (AC19-22)
|
||||
@@ -0,0 +1,38 @@
|
||||
---
|
||||
id: 3-5
|
||||
title: 3-5 Admin Booking Review & Approval
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to review, categorize, and approve or reject booking requests, So that I can manage my consultation schedule and set appropriate consultation types. Context: Integrates with: consultations table, notifications, .ics generation; Technology: Livewire Volt, Flux UI; Follows pattern: Admin action workflow. Create these notification classes in app/Notifications/:. Full implementation history: docs/stories/story-3.5-admin-booking-review-approval.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] View all pending booking requests
|
||||
- [ ] Display: client name, requested date/time, submission date
|
||||
- [ ] Show problem summary preview
|
||||
- [ ] Click to view full details
|
||||
- [ ] Sort by date (oldest first default)
|
||||
- [ ] Filter by date range
|
||||
- [ ] Full client information
|
||||
- [ ] Complete problem summary
|
||||
- [ ] Client consultation history
|
||||
- [ ] Requested date and time
|
||||
- [ ] Set consultation type:
|
||||
- [ ] If paid: set payment amount
|
||||
- [ ] If paid: add payment instructions (optional)
|
||||
- [ ] Approve button with confirmation
|
||||
- [ ] On approval:
|
||||
- [ ] Optional rejection reason field
|
||||
- [ ] Reject button with confirmation
|
||||
- [ ] On rejection:
|
||||
- [ ] Quick approve (free) button on list
|
||||
- [ ] Quick reject button on list
|
||||
- [ ] Bulk actions (optional)
|
||||
- [ ] Audit log for all decisions
|
||||
- [ ] Bilingual notifications
|
||||
- [ ] Tests for approval/rejection flow
|
||||
@@ -0,0 +1,35 @@
|
||||
---
|
||||
id: 3-6
|
||||
title: 3-6 Calendar File Generation (.ics)
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to receive a calendar file when my booking is approved, So that I can easily add the consultation to my calendar app. Context: Integrates with: Consultation model, email attachments; Technology: iCalendar format (RFC 5545); Follows pattern: Service class for generation. Full implementation history: docs/stories/story-3.6-calendar-file-generation.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Generate valid .ics file on booking approval
|
||||
- [ ] File follows iCalendar specification (RFC 5545)
|
||||
- [ ] Compatible with major calendar apps:
|
||||
- [ ] Event title: "Consultation with Libra Law Firm" (bilingual)
|
||||
- [ ] Date and time (correct timezone)
|
||||
- [ ] Duration: 45 minutes
|
||||
- [ ] Location (office address or "Phone consultation")
|
||||
- [ ] Description with:
|
||||
- [ ] Reminder: 1 hour before
|
||||
- [ ] Attach to approval email
|
||||
- [ ] Available for download from client dashboard
|
||||
- [ ] Proper MIME type (text/calendar)
|
||||
- [ ] Correct filename (consultation-{date}.ics)
|
||||
- [ ] Event title in client's preferred language
|
||||
- [ ] Description in client's preferred language
|
||||
- [ ] Valid iCalendar format (passes validators)
|
||||
- [ ] Tests for file generation
|
||||
- [ ] Tests for calendar app compatibility
|
||||
- [ ] Tests for bilingual content (Arabic/English)
|
||||
- [ ] Tests for download route authorization
|
||||
- [ ] Tests for email attachment
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: 3-7
|
||||
title: 3-7 Consultation Management
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to manage consultations throughout their lifecycle, So that I can track completed sessions, handle no-shows, and maintain accurate records. Context: Integrates with: consultations table, notifications; Technology: Livewire Volt, Flux UI; Follows pattern: Admin management dashboard. Handle these scenarios with appropriate validation and error handling:. Full implementation history: docs/stories/story-3.7-consultation-management.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] View all consultations with filters:
|
||||
- [ ] Sort by date, status, client name
|
||||
- [ ] Pagination (15/25/50 per page)
|
||||
- [ ] Quick status indicators
|
||||
- [ ] Mark consultation as completed
|
||||
- [ ] Mark consultation as no-show
|
||||
- [ ] Cancel booking on behalf of client
|
||||
- [ ] Status change confirmation
|
||||
- [ ] Reschedule appointment to new date/time
|
||||
- [ ] Validate new slot availability
|
||||
- [ ] Send notification to client
|
||||
- [ ] Generate new .ics file
|
||||
- [ ] Mark payment as received (for paid consultations)
|
||||
- [ ] Payment date recorded
|
||||
- [ ] Payment status visible in list
|
||||
- [ ] Add internal admin notes
|
||||
- [ ] Notes not visible to client
|
||||
- [ ] View notes in consultation detail
|
||||
- [ ] Edit/delete notes
|
||||
- [ ] View all consultations for a specific client
|
||||
- [ ] Linked from user profile
|
||||
- [ ] Summary statistics per client
|
||||
- [ ] Audit log for all status changes
|
||||
- [ ] Bilingual labels
|
||||
- [ ] Tests for status transitions
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 3-8
|
||||
title: 3-8 Consultation Reminders
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to receive reminder emails before my consultation, So that I don't forget my appointment and can prepare accordingly. Context: Integrates with: consultations table, Laravel scheduler, email notifications; Technology: Laravel Queue, Scheduler, Mailable; Follows pattern: Scheduled job pattern. Full implementation history: docs/stories/story-3.8-consultation-reminders.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Sent 24 hours before consultation
|
||||
- [ ] Includes:
|
||||
- [ ] Sent 2 hours before consultation
|
||||
- [ ] Includes:
|
||||
- [ ] Only for approved consultations
|
||||
- [ ] Skip cancelled consultations
|
||||
- [ ] Skip no-show consultations
|
||||
- [ ] Don't send duplicate reminders
|
||||
- [ ] Handle timezone correctly
|
||||
- [ ] Email in client's preferred language
|
||||
- [ ] Arabic template for Arabic preference
|
||||
- [ ] English template for English preference
|
||||
- [ ] Scheduled jobs run reliably
|
||||
- [ ] Retry on failure
|
||||
- [ ] Logging for debugging
|
||||
- [ ] Tests for reminder logic
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: 3-9
|
||||
title: 3-9 Guest Booking Request
|
||||
status: Draft
|
||||
date: 2026-09-27
|
||||
parent: 3
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a guest visitor, I want to submit a consultation booking request with my contact details, So that I can request legal services without needing an account first. Context: Integrates with: Availability calendar (Story 3.3), Admin booking review (Story 3.5), User creation (Epic 2); Technology: Livewire Volt, Flux UI, existing availability calendar component; Follows pattern: Client booking submission (Story 3.4), Admin approval workflow (Story 3.5). Extend the existing admin.bookings.pending component to include guest booking requests:. Full implementation history: docs/stories/story-3.9-guest-booking-request.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] **AC1:** Public `/booking` page accessible without login
|
||||
- [ ] **AC2:** Display availability calendar (reuse existing component)
|
||||
- [ ] **AC3:** Guest can select date and available time slot
|
||||
- [ ] **AC4:** Account type toggle: Individual / Company
|
||||
- [ ] **AC5:** Form fields for Individual:
|
||||
- [ ] **AC6:** Additional fields for Company:
|
||||
- [ ] **AC7:** Problem summary field (required, textarea, min 20 characters, max 2000)
|
||||
- [ ] **AC8:** Confirmation step before submission showing all entered data
|
||||
- [ ] **AC9:** Duplicate check: If email OR national_id exists in users table, show "Account already exists. Please login to book." with login link
|
||||
- [ ] **AC10:** 1-per-day limit by email: Check guest_booking_requests table for same email on same booking_date
|
||||
- [ ] **AC11:** Validate selected slot is still available
|
||||
- [ ] **AC12:** Clear error messages for all validation failures (bilingual)
|
||||
- [ ] **AC13:** On submit, create record in `guest_booking_requests` table with status 'pending'
|
||||
- [ ] **AC14:** Guest sees success page: "Request received. We will contact you soon."
|
||||
- [ ] **AC15:** Admin receives email notification about new guest booking request
|
||||
- [ ] **AC16:** Guest receives submission confirmation email
|
||||
- [ ] **AC17:** Guest booking requests appear in admin pending bookings queue with "Guest" badge
|
||||
- [ ] **AC18:** Admin can view full guest details and problem summary
|
||||
- [ ] **AC19:** Admin action: **Approve + Create Account**
|
||||
- [ ] **AC20:** Admin action: **Reject**
|
||||
- [ ] **AC21:** Admin action: **Create Account Only**
|
||||
- [ ] **AC22:** All admin actions logged in audit trail
|
||||
- [ ] **AC23:** Bilingual support (Arabic/English) for all UI and emails
|
||||
- [ ] **AC24:** Mobile-responsive design
|
||||
- [ ] **AC25:** Race condition prevention for slot availability
|
||||
- [ ] **AC26:** Comprehensive test coverage
|
||||
@@ -0,0 +1,24 @@
|
||||
---
|
||||
id: 3
|
||||
title: 3 Booking & Consultation System
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Implements the full consultation booking workflow: admin-configured working hours and blocked time, a live availability calendar, client and guest booking submission, admin approval/rejection with free/paid assignment, consultation management, .ics calendar-file generation, and 24h/2h reminders.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Calendar displays available time slots
|
||||
- [ ] Clients can submit booking requests
|
||||
- [ ] 1 consultation per day per client enforced
|
||||
- [ ] Admin can approve/reject bookings
|
||||
- [ ] Admin assigns free/paid status
|
||||
- [ ] Email notifications at each stage
|
||||
- [ ] Consultation reminders (24hr, 2hr)
|
||||
- [ ] Calendar file (.ics) generation
|
||||
- [ ] Admin can mark as completed/no-show/cancelled
|
||||
- [ ] Guests can submit booking requests from public page
|
||||
- [ ] Admin can approve guest requests and create accounts
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 4-1
|
||||
title: 4-1 Timeline Creation
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to create case timelines for clients, So that I can track and communicate progress on their legal matters. Context: Integrates with: timelines table, timeline_updates table, users table, admin_logs table; Technology: Livewire Volt, Flux UI; Follows pattern: Admin CRUD pattern (see existing admin components). Full implementation history: docs/stories/story-4.1-timeline-creation.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Select client (search by name/email) - only users with user_type 'individual' or 'company'
|
||||
- [ ] Case name/title (required)
|
||||
- [ ] Case reference number (optional, unique if provided)
|
||||
- [ ] Initial notes (optional)
|
||||
- [ ] Timeline assigned to selected client
|
||||
- [ ] Creation date automatically recorded
|
||||
- [ ] Status defaults to 'active'
|
||||
- [ ] Can create multiple timelines per client
|
||||
- [ ] Confirmation message on successful creation
|
||||
- [ ] Timeline immediately visible to client
|
||||
- [ ] Case name required
|
||||
- [ ] Case reference unique if provided
|
||||
- [ ] Client must exist
|
||||
- [ ] Audit log entry created via AdminLog model
|
||||
- [ ] Bilingual labels and messages
|
||||
- [ ] Tests for creation flow
|
||||
@@ -0,0 +1,40 @@
|
||||
---
|
||||
id: 4-2
|
||||
title: 4-2 Timeline Updates Management
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to add and edit updates within a timeline, So that I can keep clients informed about their case progress. Context: Integrates with: timeline_updates table, timelines table; Technology: Livewire Volt, rich text editor (Trix recommended); Follows pattern: Nested CRUD pattern. Full implementation history: docs/stories/story-4.2-timeline-updates-management.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Add new update to timeline
|
||||
- [ ] Update text content (required)
|
||||
- [ ] Rich text formatting supported:
|
||||
- [ ] Timestamp automatically recorded
|
||||
- [ ] Admin name automatically recorded
|
||||
- [ ] Client notified via email on new update
|
||||
- [ ] Edit existing update text
|
||||
- [ ] Edit history preserved (updated_at changes)
|
||||
- [ ] Cannot change timestamp or admin
|
||||
- [ ] Updates displayed in chronological order
|
||||
- [ ] Each update shows:
|
||||
- [ ] Visual timeline representation
|
||||
- [ ] HTML sanitization using `mews/purifier` package
|
||||
- [ ] Audit log for add/edit operations via AdminLog
|
||||
- [ ] Feature tests for all operations
|
||||
- [ ] Can add update with valid text (min 10 chars)
|
||||
- [ ] Cannot add update with empty text - validation error
|
||||
- [ ] Cannot add update with text < 10 chars - validation error
|
||||
- [ ] HTML is sanitized (script tags, XSS vectors removed)
|
||||
- [ ] Client receives notification email on new update
|
||||
- [ ] Audit log created when update is added
|
||||
- [ ] Audit log created when update is edited (includes old/new values)
|
||||
- [ ] Updates display in chronological order (oldest first)
|
||||
- [ ] Admin name and timestamp automatically recorded
|
||||
- [ ] Edit preserves original created_at, updates updated_at
|
||||
- [ ] Cannot change timestamp or admin on edit
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: 4-3
|
||||
title: 4-3 Timeline Archiving
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to archive completed cases and unarchive if needed, So that I can organize active and completed case timelines. Context: Integrates with: timelines table (status field from Story 4.1); Technology: Livewire Volt; Follows pattern: Soft state change pattern. Add these methods to app/Models/Timeline.php:. Full implementation history: docs/stories/story-4.3-timeline-archiving.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Archive button on timeline detail view (admin only)
|
||||
- [ ] Confirmation modal before archiving ("Are you sure?")
|
||||
- [ ] Status changes to 'archived'
|
||||
- [ ] Timeline remains visible to client (read-only as always)
|
||||
- [ ] No further updates can be added (show disabled state with tooltip)
|
||||
- [ ] Visual indicator shows archived status (badge + muted styling)
|
||||
- [ ] Unarchive button on archived timelines
|
||||
- [ ] Status returns to 'active'
|
||||
- [ ] Updates can be added again
|
||||
- [ ] Archiving already-archived timeline: No-op, no error shown
|
||||
- [ ] Unarchiving already-active timeline: No-op, no error shown
|
||||
- [ ] Adding update to archived timeline: Prevented with error message
|
||||
- [ ] Audit log for status changes (action: 'archive' or 'unarchive') - uses AdminLog `action` field
|
||||
- [ ] Bilingual labels (AR/EN for buttons, messages)
|
||||
- [ ] Feature tests covering all scenarios below
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: 4-4
|
||||
title: 4-4 Admin Timeline Dashboard
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want a central view to manage all timelines across all clients, So that I can efficiently track and update case progress. Context: Integrates with: timelines table, users table; Technology: Livewire Volt with pagination; Follows pattern: Admin list/dashboard pattern. resources/views/livewire/admin/timelines/index.blade.php. Full implementation history: docs/stories/story-4.4-admin-timeline-dashboard.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display all timelines with:
|
||||
- [ ] Pagination (15/25/50 per page)
|
||||
- [ ] Empty state message when no timelines exist
|
||||
- [ ] Filter by client (search/select)
|
||||
- [ ] Filter by status (active/archived/all)
|
||||
- [ ] Filter by date range (created/updated)
|
||||
- [ ] Search by case name or reference
|
||||
- [ ] Clear filters option
|
||||
- [ ] Show "No results" message when filters return empty
|
||||
- [ ] Sort by client name
|
||||
- [ ] Sort by case name
|
||||
- [ ] Sort by last updated
|
||||
- [ ] Sort by created date
|
||||
- [ ] Visual indicator for current sort column/direction
|
||||
- [ ] View timeline details
|
||||
- [ ] Add update (inline or link)
|
||||
- [ ] Archive/unarchive toggle with confirmation
|
||||
- [ ] Fast loading with eager loading
|
||||
- [ ] Bilingual support
|
||||
- [ ] Tests for filtering/sorting
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: 4-5
|
||||
title: 4-5 Client Timeline View
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to view my case timelines and updates, So that I can track the progress of my legal matters. Context: Integrates with: timelines, timeline_updates tables; Technology: Livewire Volt (read-only); Follows pattern: Client dashboard pattern. Full implementation history: docs/stories/story-4.5-client-timeline-view.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display all client's timelines
|
||||
- [ ] Active timelines prominently displayed
|
||||
- [ ] Archived timelines clearly separated
|
||||
- [ ] Visual distinction (color/icon) for status
|
||||
- [ ] Show for each:
|
||||
- [ ] Case name and reference
|
||||
- [ ] Status indicator
|
||||
- [ ] All updates in chronological order
|
||||
- [ ] Each update shows:
|
||||
- [ ] Read-only (no edit/comment)
|
||||
- [ ] No ability to archive/delete
|
||||
- [ ] Only see own timelines (403 for unauthorized access)
|
||||
- [ ] Recent updates indicator (new since last view, optional)
|
||||
- [ ] Responsive design for mobile
|
||||
- [ ] Bilingual labels and dates
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 4-6
|
||||
title: 4-6 Timeline Update Notifications
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 4
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to receive email notifications when my timeline is updated, So that I stay informed about my case progress without checking the portal. Context: Integrates with: timeline_updates creation, email system; Technology: Laravel Notifications, queued emails; Follows pattern: Event-driven notification pattern. Full implementation history: docs/stories/story-4.6-timeline-update-notifications.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Email sent when new update added to timeline
|
||||
- [ ] Triggered automatically on TimelineUpdate creation
|
||||
- [ ] Queued for performance
|
||||
- [ ] Case name and reference
|
||||
- [ ] Update summary or full text
|
||||
- [ ] Date of update
|
||||
- [ ] Link to view timeline
|
||||
- [ ] Libra branding
|
||||
- [ ] Email in client's preferred language
|
||||
- [ ] Arabic template
|
||||
- [ ] English template
|
||||
- [ ] No email for archived timeline reactivation
|
||||
- [ ] No email if client deactivated
|
||||
- [ ] Professional email template
|
||||
- [ ] Tests for notification sending
|
||||
- [ ] Error handling for failed sends
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 4
|
||||
title: 4 Case Timeline System
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
Lets the admin create and maintain one-way, text-only case timelines per client (multiple timelines per client, active/archived states), with clients able to view (read-only) their timelines and receive email notifications on updates.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Admin can create unlimited timelines per client
|
||||
- [ ] Admin can add text updates to timelines
|
||||
- [ ] Admin can edit existing updates
|
||||
- [ ] Admin can archive/unarchive timelines
|
||||
- [ ] Clients can view their timelines (read-only)
|
||||
- [ ] Clients notified via email on updates
|
||||
- [ ] Update history with timestamps preserved
|
||||
- [ ] Clear visual distinction between active/archived
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 5-1
|
||||
title: 5-1 Post Creation & Editing
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 5
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to create and edit blog posts with rich text formatting, So that I can publish professional legal content for website visitors. Context: Integrates with: posts table; Technology: Livewire Volt, TinyMCE or similar rich text editor; Follows pattern: Admin CRUD pattern. Use the mews/purifier package for HTML sanitization via the clean() helper:. Full implementation history: docs/stories/story-5.1-post-creation-editing.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Title (required, bilingual: Arabic and English)
|
||||
- [ ] Body content (required, bilingual)
|
||||
- [ ] Status (draft/published)
|
||||
- [ ] Bold, italic, underline
|
||||
- [ ] Headings (H2, H3)
|
||||
- [ ] Bullet and numbered lists
|
||||
- [ ] Links
|
||||
- [ ] Blockquotes
|
||||
- [ ] Save as draft functionality
|
||||
- [ ] Preview post before publishing
|
||||
- [ ] Edit published posts
|
||||
- [ ] Auto-save draft periodically (every 60 seconds)
|
||||
- [ ] Immediate publishing (no scheduling)
|
||||
- [ ] created_at recorded on creation
|
||||
- [ ] updated_at updated on edit
|
||||
- [ ] HTML sanitization for XSS prevention
|
||||
- [ ] Bilingual form labels
|
||||
- [ ] Audit log for create/edit
|
||||
- [ ] Tests for CRUD operations
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 5-2
|
||||
title: 5-2 Post Management Dashboard
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 5
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want a dashboard to manage all blog posts, So that I can organize, publish, and maintain content efficiently. Context: Integrates with: posts table, admin_logs table; Technology: Livewire Volt with pagination; Follows pattern: Admin list pattern (see similar components in `resources/views/livewire/admin/`). Create Volt component at: resources/views/livewire/admin/posts/index.blade.php. Full implementation history: docs/stories/story-5.2-post-management-dashboard.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display all posts with:
|
||||
- [ ] Pagination (10/25/50 per page)
|
||||
- [ ] Filter by status (draft/published/all)
|
||||
- [ ] Search by title or body content
|
||||
- [ ] Sort by date (newest/oldest)
|
||||
- [ ] Edit post
|
||||
- [ ] Delete (with confirmation)
|
||||
- [ ] Publish/unpublish toggle
|
||||
- [ ] Bulk delete option (optional) - **OUT OF SCOPE**
|
||||
- [ ] Bilingual labels
|
||||
- [ ] Audit log for delete and status change actions
|
||||
- [ ] Authorization check (admin only) on all actions
|
||||
- [ ] Tests for list operations
|
||||
- [ ] Handle post not found gracefully (race condition on delete)
|
||||
- [ ] Per-page selector visible in UI (10/25/50 options)
|
||||
- [ ] Bulk delete is **out of scope** for this story (marked optional)
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: 5-3
|
||||
title: 5-3 Post Deletion
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 5
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to permanently delete posts, So that I can remove outdated or incorrect content from the website. Context: Integrates with: posts table; Technology: Livewire Volt; Follows pattern: Permanent delete pattern. Add delete button to the post edit form (from Story 5.1) when editing an existing post:. Full implementation history: docs/stories/story-5.3-post-deletion.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Delete button on post list (primary location)
|
||||
- [ ] Delete button on post edit page (secondary location)
|
||||
- [ ] Confirmation modal dialog before deletion
|
||||
- [ ] Permanent deletion (no soft delete per PRD)
|
||||
- [ ] Success message after deletion
|
||||
- [ ] Redirect to post list after deletion from edit page
|
||||
- [ ] Admin-only access (middleware protection)
|
||||
- [ ] Audit log entry preserved
|
||||
- [ ] Old values stored in log
|
||||
- [ ] Clear warning in confirmation
|
||||
- [ ] Bilingual messages
|
||||
- [ ] Tests for deletion
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: 5-4
|
||||
title: 5-4 Public Posts Display
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 5
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor, I want to view published blog posts, So that I can read legal updates and articles from the firm. Context: Integrates with: posts table (published only); Technology: Livewire Volt (public routes); Follows pattern: Public content display. Full implementation history: docs/stories/story-5.4-public-posts-display.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Public access (no login required)
|
||||
- [ ] Display in reverse chronological order
|
||||
- [ ] Each post card shows:
|
||||
- [ ] Pagination for many posts
|
||||
- [ ] Full post content displayed
|
||||
- [ ] Clean, readable typography
|
||||
- [ ] Publication date shown
|
||||
- [ ] Back to posts list link
|
||||
- [ ] Content displayed based on current site language
|
||||
- [ ] Title and body in selected language
|
||||
- [ ] Date formatting per locale
|
||||
- [ ] Responsive design (mobile-friendly)
|
||||
- [ ] Professional typography
|
||||
- [ ] Consistent with brand colors
|
||||
- [ ] Only published posts visible
|
||||
- [ ] Fast loading
|
||||
- [ ] SEO-friendly URLs (optional per PRD)
|
||||
- [ ] Tests for display logic
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 5-5
|
||||
title: 5-5 Post Search
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 5
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a website visitor, I want to search through blog posts, So that I can find relevant legal articles and information. Context: Integrates with: posts table, public posts listing; Technology: Livewire Volt with real-time search; Follows pattern: Search component pattern. Full implementation history: docs/stories/story-5.5-post-search.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Search input on posts listing page
|
||||
- [ ] Search by title (both languages)
|
||||
- [ ] Search by body content (both languages)
|
||||
- [ ] Real-time search results (debounced)
|
||||
- [ ] "No results found" message when empty
|
||||
- [ ] Clear search button
|
||||
- [ ] Search works in both Arabic and English
|
||||
- [ ] Only searches published posts
|
||||
- [ ] Search highlights in results
|
||||
- [ ] Search suggestions
|
||||
- [ ] Debounce to reduce server load (300ms)
|
||||
- [ ] Case-insensitive search
|
||||
- [ ] Tests for search functionality
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 5
|
||||
title: 5 Posts/Blog System
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
An admin-only publishing system for legal articles/news: rich-text creation and editing, draft saving, deletion, public bilingual display in reverse-chronological order, and simple title/body search — all without login or comments.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Admin can create, edit, delete posts
|
||||
- [ ] Rich text editor for formatting
|
||||
- [ ] Draft saving capability
|
||||
- [ ] Posts publicly visible
|
||||
- [ ] Search functionality
|
||||
- [ ] Reverse chronological display
|
||||
- [ ] Bilingual content support
|
||||
- [ ] Responsive design
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 6-1
|
||||
title: 6-1 Dashboard Overview & Statistics
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to see real-time metrics and key statistics at a glance, So that I can understand the current state of my practice. Full implementation history: docs/stories/story-6.1-dashboard-overview-statistics.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Total active clients (individual + company with status = active)
|
||||
- [ ] Individual vs company breakdown (count each type)
|
||||
- [ ] Deactivated clients count
|
||||
- [ ] New clients this month (created_at in current month)
|
||||
- [ ] Pending requests count (highlighted with warning color)
|
||||
- [ ] Today's consultations (scheduled for today, approved status)
|
||||
- [ ] This week's consultations
|
||||
- [ ] This month's consultations
|
||||
- [ ] Free vs paid breakdown (consultation_type field)
|
||||
- [ ] No-show rate percentage (no-show / total completed * 100)
|
||||
- [ ] Active case timelines (status = active)
|
||||
- [ ] Archived timelines (status = archived)
|
||||
- [ ] Updates added this week (timeline_updates created in last 7 days)
|
||||
- [ ] Total published posts (status = published)
|
||||
- [ ] Posts published this month
|
||||
- [ ] Clean card-based layout using Flux UI components
|
||||
- [ ] Color-coded status indicators (gold for highlights, success green, warning colors)
|
||||
- [ ] Responsive grid (2 columns on tablet, 1 on mobile, 4 on desktop)
|
||||
- [ ] Navy blue and gold color scheme per PRD Section 7.1
|
||||
@@ -0,0 +1,34 @@
|
||||
---
|
||||
id: 6-10
|
||||
title: 6-10 Audit Log Viewer
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to view admin action history, So that I can maintain accountability and track changes. - resources/views/livewire/admin/audit-logs.blade.php - Main Volt component - app/Models/AdminLog.php - Eloquent model (if not already created in Story 1.1) - routes/web.php - Add admin route (or admin routes file) - lang/ar/audit.php - Arabic translations - lang/en/audit.php - English translations. Full implementation history: docs/stories/story-6.10-audit-log-viewer.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Paginated table of audit log entries (25 per page)
|
||||
- [ ] Each row displays:
|
||||
- [ ] Filter by action type (dropdown with available actions)
|
||||
- [ ] Filter by target type (dropdown with available targets)
|
||||
- [ ] Filter by date range (date pickers for from/to)
|
||||
- [ ] Filters apply without page reload (Livewire)
|
||||
- [ ] Reset filters button
|
||||
- [ ] Search by target ID (exact match)
|
||||
- [ ] Search updates results in real-time with debounce
|
||||
- [ ] Modal displays full log entry details
|
||||
- [ ] Shows old values in readable format (JSON pretty-printed)
|
||||
- [ ] Shows new values in readable format
|
||||
- [ ] Highlights differences between old/new for updates
|
||||
- [ ] Bilingual labels
|
||||
- [ ] Export current filtered results to CSV
|
||||
- [ ] CSV includes all displayed columns
|
||||
- [ ] CSV filename includes export date
|
||||
- [ ] Bilingual column headers based on admin's language preference
|
||||
- [ ] Friendly message when no logs exist
|
||||
- [ ] Friendly message when filters return no results
|
||||
@@ -0,0 +1,39 @@
|
||||
---
|
||||
id: 6-2
|
||||
title: 6-2 Analytics Charts
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want visual charts showing trends and historical data, So that I can identify patterns in client acquisition and consultation outcomes to make informed business decisions. Full implementation history: docs/stories/story-6.2-analytics-charts.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display new clients per month (from `users.created_at`)
|
||||
- [ ] Display consultations per month (from `consultations.scheduled_date`)
|
||||
- [ ] Two data series on same chart with legend
|
||||
- [ ] X-axis: Month labels (e.g., "Jan 2025", "Feb 2025")
|
||||
- [ ] Y-axis: Count values with appropriate scale
|
||||
- [ ] Show free vs paid consultation ratio
|
||||
- [ ] Display percentage labels on segments
|
||||
- [ ] Legend showing "Free" and "Paid" with counts
|
||||
- [ ] Monthly no-show percentage trend
|
||||
- [ ] X-axis: Month labels
|
||||
- [ ] Y-axis: Percentage (0-100%)
|
||||
- [ ] Visual threshold line at concerning rate (e.g., 20%)
|
||||
- [ ] Preset options: Last 6 months, Last 12 months
|
||||
- [ ] Custom date range picker (start/end month)
|
||||
- [ ] Charts update when range changes
|
||||
- [ ] Default selection: Last 6 months
|
||||
- [ ] Tooltips showing exact values on hover
|
||||
- [ ] Responsive sizing (charts resize with viewport)
|
||||
- [ ] Bilingual labels (Arabic/English based on locale)
|
||||
- [ ] Loading state while fetching data
|
||||
- [ ] Empty state when no data available
|
||||
- [ ] Charts section below statistics cards from Story 6.1
|
||||
- [ ] Card-based layout for each chart
|
||||
- [ ] Navy blue and gold color scheme per PRD Section 7.1
|
||||
- [ ] Responsive grid (1 column mobile, 2 columns tablet+)
|
||||
@@ -0,0 +1,37 @@
|
||||
---
|
||||
id: 6-3
|
||||
title: 6-3 Quick Actions Panel
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want quick access to pending items and common tasks, So that I can efficiently manage my daily workflow without navigating away from the dashboard. Full implementation history: docs/stories/story-6.3-quick-actions-panel.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display count badge showing number of pending consultation requests
|
||||
- [ ] Urgent indicator (red/warning styling) when pending count > 0
|
||||
- [ ] Mini list showing up to 5 most recent pending bookings with:
|
||||
- [ ] "View All" link navigating to booking management page (`admin.bookings.pending`)
|
||||
- [ ] Empty state message when no pending bookings
|
||||
- [ ] List of today's approved consultations ordered by time
|
||||
- [ ] Each item displays:
|
||||
- [ ] Quick status buttons for each consultation:
|
||||
- [ ] Empty state message when no consultations scheduled today
|
||||
- [ ] Display last 5 timeline updates across all clients
|
||||
- [ ] Each item shows:
|
||||
- [ ] Click navigates to the specific timeline (`admin.timelines.show`)
|
||||
- [ ] Empty state message when no recent updates
|
||||
- [ ] **Create Client** button - navigates to `admin.clients.individual.create`
|
||||
- [ ] **Create Post** button - navigates to `admin.posts.create`
|
||||
- [ ] **Block Time Slot** button - opens modal to block availability
|
||||
- [ ] Bell icon in admin header/navbar
|
||||
- [ ] Badge showing total pending items count (pending bookings)
|
||||
- [ ] Badge hidden when count is 0
|
||||
- [ ] Click navigates to pending bookings
|
||||
- [ ] Widgets auto-refresh via Livewire polling every 30 seconds
|
||||
- [ ] No full page reload required
|
||||
- [ ] Visual indication during refresh (subtle loading state) - Using default Livewire behavior
|
||||
@@ -0,0 +1,42 @@
|
||||
---
|
||||
id: 6-4
|
||||
title: 6-4 Data Export - User Lists
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to export user data in CSV and PDF formats, So that I can generate reports and maintain offline records. Full implementation history: docs/stories/story-6.4-data-export-user-lists.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Export all users (both individual and company clients)
|
||||
- [ ] Export individual clients only (`user_type = 'individual'`)
|
||||
- [ ] Export company clients only (`user_type = 'company'`)
|
||||
- [ ] Date range filter on `created_at` field (start date, end date)
|
||||
- [ ] Status filter: active, deactivated, or all
|
||||
- [ ] Filters combine with export type (e.g., "active individual clients created in 2024")
|
||||
- [ ] Name (`name` for individual, `company_name` for company)
|
||||
- [ ] Email (`email`)
|
||||
- [ ] Phone (`phone`)
|
||||
- [ ] User type (`user_type`: individual/company)
|
||||
- [ ] National ID / Company registration (`national_id` for individual, `company_cert_number` for company)
|
||||
- [ ] Status (`status`: active/deactivated)
|
||||
- [ ] Created date (`created_at` formatted per locale)
|
||||
- [ ] UTF-8 BOM for proper Arabic character display in Excel
|
||||
- [ ] Same data fields as CSV in tabular format
|
||||
- [ ] Libra branding header (logo, firm name)
|
||||
- [ ] Generation timestamp in footer
|
||||
- [ ] Page numbers if multiple pages
|
||||
- [ ] Professional formatting with brand colors (Navy #0A1F44, Gold #D4AF37)
|
||||
- [ ] Column headers based on admin's `preferred_language` setting
|
||||
- [ ] Date formatting per locale (DD/MM/YYYY for Arabic, MM/DD/YYYY for English)
|
||||
- [ ] PDF title and footer text bilingual
|
||||
- [ ] Export section accessible from Admin User Management page
|
||||
- [ ] Filter form with: user type dropdown, status dropdown, date range picker
|
||||
- [ ] "Export CSV" and "Export PDF" buttons
|
||||
- [ ] Loading indicator during export generation
|
||||
- [ ] Success toast on download start
|
||||
- [ ] Error toast if export fails
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 6-5
|
||||
title: 6-5 Data Export - Consultation Records
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to export consultation/booking data in CSV and PDF formats, So that I can generate reports for accounting, analyze consultation patterns, and maintain offline records of client interactions. Follow the export pattern established in Story 6.4. Reuse any base export functionality created there. Full implementation history: docs/stories/story-6.5-data-export-consultation-records.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Export all consultations
|
||||
- [ ] Export filtered subset based on criteria below
|
||||
- [ ] Date range (booking_date between start/end)
|
||||
- [ ] Consultation type (free/paid)
|
||||
- [ ] Status (pending/approved/completed/no-show/cancelled/rejected)
|
||||
- [ ] Payment status (pending/received/na)
|
||||
- [ ] Client name (from user relationship)
|
||||
- [ ] Date and time (booking_date, booking_time)
|
||||
- [ ] Consultation type (free/paid)
|
||||
- [ ] Status
|
||||
- [ ] Payment status
|
||||
- [ ] Problem summary (truncated in PDF if > 500 chars)
|
||||
- [ ] CSV format with streaming download
|
||||
- [ ] PDF format with professional layout and Libra branding
|
||||
- [ ] Column headers based on admin's preferred language
|
||||
- [ ] Use translation keys from `lang/{locale}/export.php`
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 6-6
|
||||
title: 6-6 Data Export - Timeline Reports
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to export timeline and case data, So that I can maintain records and generate case reports. Context: Follows pattern: Story 6.4 (User Lists Export) and Story 6.5 (Consultation Export) - same UI layout, filter approach, and export mechanisms; Integrates with: Timeline model, TimelineUpdate model, User model; Technology: Livewire Volt, Flux UI, league/csv, barryvdh/laravel-dompdf. Full implementation history: docs/stories/story-6.6-data-export-timeline-reports.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Export all timelines (across all clients)
|
||||
- [ ] Export timelines for specific client (client selector/search)
|
||||
- [ ] Status filter (active/archived/all)
|
||||
- [ ] Date range filter (created_at)
|
||||
- [ ] Client filter (search by name/email)
|
||||
- [ ] Case name and reference
|
||||
- [ ] Client name
|
||||
- [ ] Status
|
||||
- [ ] Created date
|
||||
- [ ] Number of updates
|
||||
- [ ] Last update date
|
||||
- [ ] CSV format with bilingual headers
|
||||
- [ ] PDF format with Libra branding
|
||||
- [ ] Include update content toggle (full content vs summary only)
|
||||
- [ ] When enabled, PDF includes all update entries per timeline
|
||||
- [ ] Filter controls match Story 6.4/6.5 layout
|
||||
- [ ] Export buttons clearly visible
|
||||
- [ ] Loading state during export generation
|
||||
- [ ] Success/error feedback messages
|
||||
@@ -0,0 +1,52 @@
|
||||
---
|
||||
id: 6-7
|
||||
title: 6-7 Monthly Statistics Report
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to generate comprehensive monthly PDF reports from the admin dashboard, So that I can archive business performance records, share summaries with stakeholders, and track month-over-month trends. Full implementation history: docs/stories/story-6.7-monthly-statistics-report.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] "Generate Monthly Report" button in admin dashboard (below metrics cards or in a Reports section)
|
||||
- [ ] Month/year selector dropdown (default: previous month)
|
||||
- [ ] Selectable range: last 12 months only (no future months)
|
||||
- [ ] Libra logo and branding
|
||||
- [ ] Report title: "Monthly Statistics Report"
|
||||
- [ ] Period: Month and Year (e.g., "December 2025")
|
||||
- [ ] Generated date and time
|
||||
- [ ] List of sections with page numbers
|
||||
- [ ] Non-clickable (simple text list for print compatibility)
|
||||
- [ ] Key highlights (2-3 bullet points)
|
||||
- [ ] Month-over-month comparison if prior month data exists
|
||||
- [ ] New clients registered this month
|
||||
- [ ] Total active clients (end of month)
|
||||
- [ ] Individual vs company breakdown
|
||||
- [ ] Client growth trend (compared to previous month)
|
||||
- [ ] Total consultations this month
|
||||
- [ ] Approved/Completed/Cancelled/No-show breakdown
|
||||
- [ ] Free vs paid ratio
|
||||
- [ ] No-show rate percentage
|
||||
- [ ] Pie chart: Consultation types (rendered as image)
|
||||
- [ ] Active timelines (end of month)
|
||||
- [ ] New timelines created this month
|
||||
- [ ] Timeline updates added this month
|
||||
- [ ] Archived timelines this month
|
||||
- [ ] Posts published this month
|
||||
- [ ] Total published posts (cumulative)
|
||||
- [ ] Line chart showing monthly consultations trend (last 6 months ending with selected month)
|
||||
- [ ] Rendered as base64 PNG image
|
||||
- [ ] Professional A4 portrait layout
|
||||
- [ ] Libra branding: Navy Blue (#0A1F44) headers, Gold (#D4AF37) accents
|
||||
- [ ] Consistent typography and spacing
|
||||
- [ ] Print-friendly (no dark backgrounds, adequate margins)
|
||||
- [ ] Bilingual: Arabic or English based on admin's `preferred_language` setting
|
||||
- [ ] Loading indicator with "Generating report..." message during PDF creation
|
||||
- [ ] Disable generate button while processing
|
||||
- [ ] Auto-download PDF on completion
|
||||
- [ ] Success toast notification after download starts
|
||||
- [ ] Error handling with user-friendly message if generation fails
|
||||
@@ -0,0 +1,26 @@
|
||||
---
|
||||
id: 6-8
|
||||
title: 6-8 System Settings
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to configure system-wide settings, So that I can customize the platform to my needs. Add preferred_language column to users table:. Full implementation history: docs/stories/story-6.8-system-settings.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Admin name
|
||||
- [ ] Email
|
||||
- [ ] Password change
|
||||
- [ ] Preferred language
|
||||
- [ ] Display current sender email from `config('mail.from.address')`
|
||||
- [ ] Display current sender name from `config('mail.from.name')`
|
||||
- [ ] "Send Test Email" button that sends a test email to admin's email address
|
||||
- [ ] Success/error feedback after test email attempt
|
||||
- [ ] Settings saved and applied immediately
|
||||
- [ ] Validation for all inputs
|
||||
- [ ] Flash messages for success/error states
|
||||
- [ ] Password fields cleared after successful update
|
||||
@@ -0,0 +1,30 @@
|
||||
---
|
||||
id: 6-9
|
||||
title: 6-9 Legal Pages Editor
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 6
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to edit Terms of Service and Privacy Policy pages, So that I can maintain legal compliance and update policies. This project uses **class-based Volt components** for interactivity. Follow existing patterns in resources/views/livewire/. Full implementation history: docs/stories/story-6.9-legal-pages-editor.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Terms of Service (`/page/terms`)
|
||||
- [ ] Privacy Policy (`/page/privacy`)
|
||||
- [ ] Rich text editor using Quill.js (lightweight, RTL-friendly)
|
||||
- [ ] Bilingual content with Arabic/English tabs in editor UI
|
||||
- [ ] Save and publish button updates database immediately
|
||||
- [ ] Preview opens modal showing rendered content in selected language
|
||||
- [ ] HTML content sanitized before save (prevent XSS)
|
||||
- [ ] Accessible under Admin Dashboard > Settings section
|
||||
- [ ] Sidebar item: "Legal Pages" or integrate into Settings page
|
||||
- [ ] List view showing both pages with "Edit" action
|
||||
- [ ] Edit page shows language tabs (Arabic | English) above editor
|
||||
- [ ] Pages accessible from footer links (no auth required)
|
||||
- [ ] Route: `/page/{slug}` where slug is `terms` or `privacy`
|
||||
- [ ] Content displayed in user's current language preference
|
||||
- [ ] Last updated timestamp displayed at bottom of page
|
||||
- [ ] Professional layout consistent with site design (navy/gold)
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 6
|
||||
title: 6 Admin Dashboard
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
A centralized control panel for the admin: overview statistics, Chart.js analytics, a quick-actions panel, CSV/PDF data exports (users, consultations, timelines, monthly stats), system settings, a legal-pages (Terms/Privacy) editor, and an audit-log viewer.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Overview dashboard with key metrics
|
||||
- [ ] Charts for trends and analytics
|
||||
- [ ] Quick access to pending actions
|
||||
- [ ] Data export (CSV, PDF)
|
||||
- [ ] System settings management
|
||||
- [ ] Legal pages editor (Terms, Privacy)
|
||||
- [ ] Audit log visibility
|
||||
- [ ] Responsive design for tablet use
|
||||
@@ -0,0 +1,44 @@
|
||||
---
|
||||
id: 7-1
|
||||
title: 7-1 Client Dashboard Overview
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want a dashboard showing my key information at a glance, So that I can quickly see upcoming consultations and case updates. Full implementation history: docs/stories/story-7.1-client-dashboard-overview.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Display "Welcome, {client name}" greeting
|
||||
- [ ] Use localized greeting based on user's preferred language
|
||||
- [ ] Show current date in user's locale format
|
||||
- [ ] Display next approved consultation (or "No upcoming consultations" if none)
|
||||
- [ ] Show consultation date/time formatted per locale (AR: DD/MM/YYYY, EN: MM/DD/YYYY)
|
||||
- [ ] Show time in 12-hour format (AM/PM)
|
||||
- [ ] Display type badge: "Free" (green) or "Paid" (gold)
|
||||
- [ ] Display status badge with appropriate color
|
||||
- [ ] "View Details" link to consultation details (Story 7.2)
|
||||
- [ ] Display count of active timelines
|
||||
- [ ] Show preview of most recent update (truncated to ~100 chars)
|
||||
- [ ] "View All Cases" link to timelines list (Story 7.3)
|
||||
- [ ] Empty state: "No active cases" with muted styling
|
||||
- [ ] Display last 3 timeline updates across all user's cases
|
||||
- [ ] Each update shows: case name, update date, preview text
|
||||
- [ ] "View Timeline" link for each update
|
||||
- [ ] Empty state: "No recent updates"
|
||||
- [ ] Display count of pending booking requests
|
||||
- [ ] Show booking limit indicator:
|
||||
- [ ] "Book Consultation" button linking to booking page (Story 7.5)
|
||||
- [ ] Disable button if daily limit reached
|
||||
- [ ] Card-based layout using Flux UI components
|
||||
- [ ] Color scheme: Navy (#0A1F44) background sections, Gold (#D4AF37) accents
|
||||
- [ ] Mobile-first responsive (stack cards vertically on mobile)
|
||||
- [ ] All text content bilingual (Arabic RTL / English LTR)
|
||||
- [ ] Use consistent spacing: `gap-6` between cards, `p-6` card padding
|
||||
- [ ] No consultations: Show empty state with "Book your first consultation" CTA
|
||||
- [ ] No timelines: Show empty state "No cases assigned yet"
|
||||
- [ ] No updates: Show empty state "No recent updates"
|
||||
- [ ] Loading state: Show skeleton loaders while data fetches
|
||||
@@ -0,0 +1,33 @@
|
||||
---
|
||||
id: 7-2
|
||||
title: 7-2 My Consultations View
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to view all my consultations, So that I can track upcoming appointments and review past sessions. - resources/views/livewire/client/consultations.blade.php - Main Volt component - routes/web.php - Add route within client middleware group. Full implementation history: docs/stories/story-7.2-my-consultations-view.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Date and time (formatted per locale)
|
||||
- [ ] Consultation type (free/paid)
|
||||
- [ ] Status (approved/pending)
|
||||
- [ ] Payment status (for paid consultations)
|
||||
- [ ] Download .ics calendar file button
|
||||
- [ ] Submitted bookings awaiting approval
|
||||
- [ ] Submission date
|
||||
- [ ] Problem summary preview (truncated)
|
||||
- [ ] Status: "Pending Review"
|
||||
- [ ] Historical consultations
|
||||
- [ ] Status (completed/cancelled/no-show)
|
||||
- [ ] Date and type
|
||||
- [ ] Visual status indicators (badges with colors)
|
||||
- [ ] Sort by date (default: newest first for past)
|
||||
- [ ] Pagination if many consultations (10 per page)
|
||||
- [ ] No edit/cancel capabilities (read-only)
|
||||
- [ ] "No upcoming consultations" message with link to book
|
||||
- [ ] "No pending requests" message
|
||||
- [ ] "No past consultations" message
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: 7-3
|
||||
title: 7-3 My Cases/Timelines View (Dashboard Integration)
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to access my case timelines from the dashboard navigation, So that I can easily track the progress of my legal matters from one central location. Context: Story 4.5: Client Timeline View - MUST be complete (provides all timeline components); Story 7.1: Client Dashboard Overview - MUST be complete (provides dashboard layout and navigation). Full implementation history: docs/stories/story-7.3-my-cases-timelines-view.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] "My Cases" navigation item added to client dashboard sidebar/nav
|
||||
- [ ] Navigation links to `route('client.timelines.index')`
|
||||
- [ ] Active state shown when on timeline routes
|
||||
- [ ] Icon: folder or briefcase icon for cases
|
||||
- [ ] "My Cases" widget card displays:
|
||||
- [ ] Widget shows empty state if no cases exist
|
||||
- [ ] Timeline pages use client dashboard layout (consistent header/nav)
|
||||
- [ ] Breadcrumbs: Dashboard > My Cases (on index) - *Not implemented: would require modifying Story 4.5 components*
|
||||
- [ ] Breadcrumbs: Dashboard > My Cases > [Case Name] (on show) - *Not implemented: would require modifying Story 4.5 components*
|
||||
- [ ] Navigation label translated (AR/EN)
|
||||
- [ ] Widget content translated (AR/EN)
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: 7-4
|
||||
title: 7-4 My Profile View
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to view my profile information, So that I can verify my account details are correct. Full implementation history: docs/stories/story-7.4-my-profile-view.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Full name displayed
|
||||
- [ ] National ID displayed
|
||||
- [ ] Email address displayed
|
||||
- [ ] Phone number displayed
|
||||
- [ ] Preferred language displayed
|
||||
- [ ] Account created date displayed
|
||||
- [ ] Company name displayed
|
||||
- [ ] Company certificate/registration number displayed
|
||||
- [ ] Contact person name displayed
|
||||
- [ ] Contact person ID displayed
|
||||
- [ ] Email address displayed
|
||||
- [ ] Phone number displayed
|
||||
- [ ] Preferred language displayed
|
||||
- [ ] Account created date displayed
|
||||
- [ ] Account type indicator (Individual/Company badge)
|
||||
- [ ] No edit capabilities (read-only view)
|
||||
- [ ] Message: "Contact admin to update your information"
|
||||
- [ ] Logout button with confirmation redirect
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 7-5
|
||||
title: 7-5 New Booking Interface
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to submit new consultation booking requests, So that I can schedule meetings with the lawyer. Reuse availability calendar from Story 3.3 and booking submission from Story 3.4. Full implementation history: docs/stories/story-7.5-new-booking-interface.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Quick access from dashboard
|
||||
- [ ] Book Now button in navigation
|
||||
- [ ] Calendar showing available dates
|
||||
- [ ] Available time slots for selected date
|
||||
- [ ] Selected date/time (display)
|
||||
- [ ] Problem summary (required, textarea)
|
||||
- [ ] Submit button
|
||||
- [ ] Enforce 1 booking per day limit
|
||||
- [ ] Show warning if already booked that day
|
||||
- [ ] Prevent booking on unavailable slots
|
||||
- [ ] Confirmation before submission
|
||||
- [ ] Success message with "Pending Review" status
|
||||
- [ ] Redirect to consultations list
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 7-6
|
||||
title: 7-6 Booking Limit Indicator
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 7
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to see my booking status and limits clearly, So that I understand when I can book consultations. - resources/views/livewire/client/booking-status.blade.php - Reusable status component. Full implementation history: docs/stories/story-7.6-booking-limit-indicator.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Dashboard widget showing booking status
|
||||
- [ ] Booking page status banner
|
||||
- [ ] "You can book a consultation today" (when no booking exists for today)
|
||||
- [ ] "You already have a booking for today" (when pending/approved booking exists for today)
|
||||
- [ ] "You have a pending request for [date]" (shows first pending request date)
|
||||
- [ ] Pass `bookedDates` array to availability calendar component
|
||||
- [ ] Calendar marks user's booked dates as unavailable (distinct styling)
|
||||
- [ ] Visual indicator differentiates "user already booked" from "no slots available"
|
||||
- [ ] Clear messaging about 1-per-day limit
|
||||
- [ ] Bilingual messages (Arabic/English)
|
||||
- [ ] Handle multiple pending requests (show count or list)
|
||||
- [ ] Handle cancelled bookings (should not block new booking)
|
||||
- [ ] Loading state while fetching booking status
|
||||
@@ -0,0 +1,21 @@
|
||||
---
|
||||
id: 7
|
||||
title: 7 Client Dashboard
|
||||
status: Ready for Dev
|
||||
date: 2026-09-27
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
The authenticated client portal: an overview dashboard, views of upcoming/past consultations and case timelines (read-mostly), profile viewing, a new-booking interface, and a booking-limit (1/day) indicator — all mobile-responsive.
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Client overview dashboard
|
||||
- [ ] View upcoming and past consultations
|
||||
- [ ] Download calendar files
|
||||
- [ ] View case timelines (read-only)
|
||||
- [ ] View profile information
|
||||
- [ ] Submit new booking requests
|
||||
- [ ] Booking limit enforcement (1 per day)
|
||||
- [ ] Responsive mobile design
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 8-1
|
||||
title: 8-1 Email Infrastructure Setup
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 8
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a developer, I want to configure email sending infrastructure and base templates, So that all emails have consistent branding and reliable delivery. Full implementation history: docs/stories/story-8.1-email-infrastructure-setup.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] MAIL_MAILER configured via .env
|
||||
- [ ] MAIL_HOST, MAIL_PORT, MAIL_USERNAME, MAIL_PASSWORD
|
||||
- [ ] MAIL_ENCRYPTION (TLS)
|
||||
- [ ] MAIL_FROM_ADDRESS: no-reply@libra.ps
|
||||
- [ ] MAIL_FROM_NAME: Libra Law Firm / مكتب ليبرا للمحاماة
|
||||
- [ ] Libra logo in header
|
||||
- [ ] Navy blue (#0A1F44) and gold (#D4AF37) colors
|
||||
- [ ] Professional typography
|
||||
- [ ] Footer with firm contact info
|
||||
- [ ] Mobile-responsive layout
|
||||
- [ ] Plain text fallback generation (auto-generated from HTML)
|
||||
- [ ] Queue configuration for async sending (database driver)
|
||||
- [ ] Email logging for debugging (log channel)
|
||||
@@ -0,0 +1,27 @@
|
||||
---
|
||||
id: 8-10
|
||||
title: 8-10 Admin Notification - System Events
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 8
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As an admin, I want to be notified of critical system events, So that I can address issues promptly. - app/Notifications/SystemErrorNotification.php - app/Notifications/QueueFailureNotification.php - app/Contracts/ShouldNotifyAdmin.php (marker interface) - app/Services/AdminNotificationService.php (rate limiting logic). Full implementation history: docs/stories/story-8.10-admin-notification-system-events.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Email delivery failures (SMTP errors, bounces)
|
||||
- [ ] Scheduled job failures (Laravel scheduler)
|
||||
- [ ] Queue job failures
|
||||
- [ ] Critical application errors (database, payment, etc.)
|
||||
- [ ] Event type and description
|
||||
- [ ] Timestamp (formatted per locale)
|
||||
- [ ] Relevant details (error message, stack trace summary, job name)
|
||||
- [ ] Recommended action (if applicable)
|
||||
- [ ] Environment indicator (production/staging)
|
||||
- [ ] Sent immediately using sync mail driver (not queued)
|
||||
- [ ] Clear subject line indicating urgency with event type
|
||||
- [ ] Rate limited: max 1 notification per error type per 15 minutes
|
||||
- [ ] Uses base email template from Story 8.1
|
||||
@@ -0,0 +1,29 @@
|
||||
---
|
||||
id: 8-2
|
||||
title: 8-2 Welcome Email (Account Created)
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 8
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a new client, I want to receive a welcome email with my login credentials, So that I can access the platform. - Base email template with Libra branding (navy #0A1F44, gold #D4AF37) - Queue configuration for async email delivery - SMTP configuration via .env. Full implementation history: docs/stories/story-8.2-welcome-email.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Sent automatically on user creation by admin
|
||||
- [ ] Queued for performance (implements `ShouldQueue`)
|
||||
- [ ] Triggered via admin creation action (recommended approach per Technical Notes)
|
||||
- [ ] Personalized greeting (name/company)
|
||||
- [ ] "Your account has been created" message
|
||||
- [ ] Login credentials (email, password)
|
||||
- [ ] Login URL link with button
|
||||
- [ ] Brief platform introduction
|
||||
- [ ] Contact info for questions
|
||||
- [ ] Email in user's `preferred_language` field
|
||||
- [ ] Default to Arabic ('ar') if `preferred_language` is null
|
||||
- [ ] Arabic template
|
||||
- [ ] English template
|
||||
- [ ] Professional branding (inherits from base template in Story 8.1)
|
||||
- [ ] Call-to-action button: "Login Now" / "تسجيل الدخول"
|
||||
@@ -0,0 +1,32 @@
|
||||
---
|
||||
id: 8-3
|
||||
title: 8-3 Booking Submitted Confirmation
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 8
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to receive confirmation when I submit a booking request, So that I know my request was received and what to expect next. Send the email after successful consultation creation. Typical location:. Full implementation history: docs/stories/story-8.3-booking-submitted-confirmation.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Sent immediately after successful consultation creation
|
||||
- [ ] Consultation status: pending
|
||||
- [ ] Email queued for async delivery
|
||||
- [ ] Subject line: "Your consultation request has been submitted" / "تم استلام طلب الاستشارة"
|
||||
- [ ] Personalized greeting with client name
|
||||
- [ ] "Your consultation request has been submitted" message
|
||||
- [ ] Requested date and time (formatted per user's language preference)
|
||||
- [ ] Problem summary preview (first 200 characters, with "..." if truncated)
|
||||
- [ ] "Pending Review" status note with visual indicator
|
||||
- [ ] Expected response timeframe: "We will review your request and respond within 1-2 business days"
|
||||
- [ ] Contact information for questions
|
||||
- [ ] Email sent in client's `preferred_language` (default: 'ar')
|
||||
- [ ] Arabic template for Arabic users
|
||||
- [ ] English template for English users
|
||||
- [ ] Uses base email template from Story 8.1
|
||||
- [ ] No action required message (informational only)
|
||||
- [ ] Professional template with Libra branding
|
||||
- [ ] Gold call-to-action style for "View My Bookings" link (optional)
|
||||
@@ -0,0 +1,25 @@
|
||||
---
|
||||
id: 8-4
|
||||
title: 8-4 Booking Approved Email
|
||||
status: QA Review
|
||||
date: 2026-09-27
|
||||
parent: 8
|
||||
---
|
||||
|
||||
## Description
|
||||
|
||||
As a client, I want to receive notification when my booking is approved, So that I can confirm the appointment and add it to my calendar. Full implementation history: docs/stories/story-8.4-booking-approved-email.md
|
||||
|
||||
## Acceptance Criteria
|
||||
|
||||
- [ ] Sent on booking approval by admin
|
||||
- [ ] "Your consultation has been approved"
|
||||
- [ ] Confirmed date and time
|
||||
- [ ] Duration (45 minutes)
|
||||
- [ ] Consultation type (free/paid)
|
||||
- [ ] If paid: amount and payment instructions
|
||||
- [ ] .ics calendar file attached
|
||||
- [ ] "Add to Calendar" button
|
||||
- [ ] Location/contact information
|
||||
- [ ] Email in client's preferred language
|
||||
- [ ] Valid .ics calendar file
|
||||
Some files were not shown because too many files have changed in this diff Show More
Reference in New Issue
Block a user