mirror of https://github.com/docusealco/docuseal
You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
60 lines
3.4 KiB
60 lines
3.4 KiB
# Enhancement Scope and Integration Strategy
|
|
|
|
## Enhancement Overview
|
|
|
|
**Enhancement Type:** ✅ **Major Feature Addition** (3-Portal Cohort Management System)
|
|
|
|
**Scope:** Transform the single-portal DocuSeal platform into a specialized 3-portal cohort management system for South African private training institutions. The system will manage training cohorts (learnerships, internships, candidacies) through a coordinated workflow involving institution admins, students, and sponsors.
|
|
|
|
**Integration Impact:** ✅ **Significant Impact** (substantial existing code changes required)
|
|
|
|
## Integration Approach
|
|
|
|
**Code Integration Strategy:**
|
|
- **Additive Approach:** All new functionality will be added as new models, controllers, and components without modifying existing DocuSeal core logic
|
|
- **Extension Pattern:** Extend existing authentication and authorization to support new role types
|
|
- **Service Layer:** Create new service objects in `lib/cohorts/` directory for cohort-specific business logic
|
|
- **Event-Driven:** Leverage existing webhook infrastructure for cohort workflow notifications
|
|
|
|
**Database Integration:**
|
|
- **New Tables:** Create 5 new tables (`cohorts`, `cohort_enrollments`, `institutions`, `sponsors`, `document_verifications`) with foreign keys to existing tables
|
|
- **No Schema Modifications:** Existing tables remain unchanged, only new relationships added
|
|
- **Migration Strategy:** Sequential migrations with rollback capability, tested on production-like data
|
|
- **Data Integrity:** Use database transactions for cohort state transitions
|
|
|
|
**API Integration:**
|
|
- **Endpoint Extension:** New endpoints under `/api/v1/cohorts/*` following existing RESTful patterns
|
|
- **Authentication Reuse:** Leverage existing Devise + JWT authentication without modification
|
|
- **Submission Integration:** Use existing submission APIs for document signing workflows
|
|
- **Versioning:** No new API version needed, endpoints extend v1
|
|
|
|
**UI Integration:**
|
|
- **Portal Architecture:** Three separate Vue-based portals (Admin, Student, Sponsor) with custom TailwindCSS design
|
|
- **Component Reuse:** Embed existing DocuSeal form builder and signing components within new portal frameworks
|
|
- **Navigation:** Role-based portal switching via new navigation layer
|
|
- **Design System:** Custom TailwindCSS (replacing DaisyUI) for portals while maintaining mobile responsiveness
|
|
|
|
## Compatibility Requirements
|
|
|
|
**Existing API Compatibility:** ✅ **MAINTAINED**
|
|
- All new endpoints follow existing DocuSeal API patterns
|
|
- No breaking changes to existing public APIs
|
|
- Existing authentication mechanisms remain unchanged
|
|
|
|
**Database Schema Compatibility:** ✅ **MAINTAINED**
|
|
- New tables only, no modifications to existing tables
|
|
- Foreign key relationships to existing tables (users, submissions, templates)
|
|
- Backward compatibility through additive schema changes
|
|
|
|
**UI/UX Consistency:** ✅ **ADAPTED**
|
|
- **Challenge:** PRD specifies custom UI/UX (not DaisyUI) for portals
|
|
- **Solution:** Maintain mobile-first responsive principles, consistent interaction patterns, but allow custom design system
|
|
- **Existing UI:** DocuSeal's existing DaisyUI interface remains unchanged for legacy features
|
|
|
|
**Performance Impact:** ✅ **ACCEPTABLE**
|
|
- **Target:** Not exceed current memory usage by more than 20%
|
|
- **Mitigation:** Pagination, lazy loading, background processing for large cohorts
|
|
- **Monitoring:** Extend existing metrics to track cohort-specific performance
|
|
|
|
---
|