update docs.
This commit is contained in:
@@ -18,27 +18,37 @@ graph TB
|
||||
subgraph "Application Layer"
|
||||
F[Flask App] --> G[Main Blueprint]
|
||||
F --> H[Auth Blueprint]
|
||||
G --> I[IMAP Service]
|
||||
G --> J[Folder Management]
|
||||
H --> K[User Authentication]
|
||||
G --> I[Folders Blueprint]
|
||||
G --> J[IMAP Blueprint]
|
||||
G --> K[Emails Blueprint]
|
||||
I --> L[Folder CRUD Operations]
|
||||
J --> M[IMAP Configuration & Sync]
|
||||
K --> N[Email Processing]
|
||||
H --> O[User Authentication]
|
||||
end
|
||||
|
||||
subgraph "Service Layer"
|
||||
P[IMAP Service] --> Q[Email Operations]
|
||||
R[Processed Emails Service] --> S[Email Tracking]
|
||||
end
|
||||
|
||||
subgraph "Data Layer"
|
||||
L[PostgreSQL] --> M[User Model]
|
||||
L --> N[Folder Model]
|
||||
M --> O[IMAP Configuration]
|
||||
N --> P[Folder Rules]
|
||||
N --> Q[Email Metadata]
|
||||
T[PostgreSQL] --> U[User Model]
|
||||
T --> V[Folder Model]
|
||||
T --> W[ProcessedEmail Model]
|
||||
U --> X[IMAP Configuration]
|
||||
V --> Y[Folder Rules & Metadata]
|
||||
W --> Z[Email Processing Status]
|
||||
end
|
||||
|
||||
subgraph "External Services"
|
||||
R[IMAP Server] --> I
|
||||
S[Future AI Service] --> I
|
||||
AA[IMAP Server] --> P
|
||||
end
|
||||
|
||||
D --> F
|
||||
F --> L
|
||||
I --> R
|
||||
F --> T
|
||||
P --> AA
|
||||
Q --> R
|
||||
```
|
||||
|
||||
## System Components
|
||||
@@ -62,11 +72,10 @@ The Flask application follows a modular blueprint architecture:
|
||||
Implements the factory pattern for creating Flask application instances with configuration support.
|
||||
|
||||
#### Main Blueprint
|
||||
Handles core application functionality:
|
||||
- Folder CRUD operations
|
||||
- IMAP configuration and testing
|
||||
- Folder synchronization
|
||||
- User interface endpoints
|
||||
The main application blueprint coordinates all core functionality through sub-blueprints:
|
||||
- **Folders Blueprint**: Handles folder CRUD operations, type management, and user interface
|
||||
- **IMAP Blueprint**: Manages IMAP configuration, connection testing, and folder synchronization
|
||||
- **Emails Blueprint**: Processes email operations and pending email management
|
||||
|
||||
#### Auth Blueprint
|
||||
Manages user authentication:
|
||||
@@ -74,7 +83,26 @@ Manages user authentication:
|
||||
- Password validation and hashing
|
||||
- Session management
|
||||
|
||||
### 3. Data Layer
|
||||
### 3. Service Layer
|
||||
|
||||
The application implements a service layer pattern for business logic:
|
||||
|
||||
#### IMAP Service
|
||||
Handles communication with IMAP servers:
|
||||
- Connection management and authentication
|
||||
- Folder listing and synchronization
|
||||
- Email retrieval and metadata extraction
|
||||
- Connection testing and validation
|
||||
- Email UID tracking for processed emails
|
||||
|
||||
#### Processed Emails Service
|
||||
Manages email processing status tracking:
|
||||
- Records which emails have been processed
|
||||
- Provides pending email counts
|
||||
- Handles bulk email processing operations
|
||||
- Maintains email processing history
|
||||
|
||||
### 4. Data Layer
|
||||
|
||||
The system uses PostgreSQL with SQLAlchemy ORM for data persistence:
|
||||
|
||||
@@ -92,8 +120,17 @@ Stores email organization rules and metadata:
|
||||
- Relationship: Foreign key to user
|
||||
- Rule definition: Natural language rule text
|
||||
- Organization settings: Priority, enable/disable flag
|
||||
- Email metrics: Total count, pending count
|
||||
- Email metrics: Total count, pending count, emails count
|
||||
- Email metadata: Recent emails information in JSON format
|
||||
- Folder types: Tidy, Destination, or Ignore
|
||||
|
||||
#### ProcessedEmail Model
|
||||
Tracks email processing status:
|
||||
- Primary key: Integer auto-increment ID
|
||||
- Relationships: Foreign keys to User and Folder
|
||||
- Email UID tracking: Unique identifiers from IMAP server
|
||||
- Processing status: Pending or processed flags
|
||||
- Timestamps: First seen, processed, and update times
|
||||
|
||||
### 4. External Services
|
||||
|
||||
@@ -178,19 +215,19 @@ sequenceDiagram
|
||||
- **Benefits**: Supports multiple environments (development, testing, production)
|
||||
|
||||
### 2. Blueprint Pattern
|
||||
- **Implementation**: Separated functionality in [`app/routes.py`](app/routes.py:9) and [`app/auth.py`](app/auth.py:9)
|
||||
- **Purpose**: Modularize application features
|
||||
- **Benefits**: Code organization, easier testing, scalability
|
||||
- **Implementation**: Modular blueprint structure in [`app/routes.py`](app/routes.py:12)
|
||||
- **Purpose**: Modularize application features into logical groups
|
||||
- **Benefits**: Code organization, easier testing, scalability, clear separation of concerns
|
||||
|
||||
### 3. Service Layer Pattern
|
||||
- **Implementation**: IMAP service in [`app/imap_service.py`](app/imap_service.py:10)
|
||||
- **Implementation**: IMAP service in [`app/imap_service.py`](app/imap_service.py:11) and Processed Emails service in [`app/processed_emails_service.py`](app/processed_emails_service.py:7)
|
||||
- **Purpose**: Encapsulate business logic and external communication
|
||||
- **Benefits**: Separation of concerns, reusability, testability
|
||||
- **Benefits**: Separation of concerns, reusability, testability, centralized business rules
|
||||
|
||||
### 4. Repository Pattern
|
||||
- **Implementation**: SQLAlchemy models in [`app/models.py`](app/models.py:13)
|
||||
- **Purpose**: Abstract data access layer
|
||||
- **Benefits**: Database independence, centralized query logic
|
||||
- **Benefits**: Database independence, centralized query logic, type safety
|
||||
|
||||
## Security Considerations
|
||||
|
||||
@@ -229,14 +266,22 @@ sequenceDiagram
|
||||
## Scalability
|
||||
|
||||
### 1. Architecture
|
||||
- Modular design supports feature expansion
|
||||
- Service layer allows for additional email providers
|
||||
- Database schema designed for growth
|
||||
- Modular blueprint structure supports feature expansion
|
||||
- Service layer allows for additional email providers and processing logic
|
||||
- Database schema designed for growth with processed email tracking
|
||||
- Current folder type system (Tidy, Destination, Ignore) provides flexible organization
|
||||
|
||||
### 2. Future Enhancements
|
||||
### 2. Current Implementation Status
|
||||
- IMAP connectivity and folder synchronization fully implemented
|
||||
- Email processing status tracking operational
|
||||
- Folder type management with UI components complete
|
||||
- Authentication system with session management functional
|
||||
|
||||
### 3. Future Enhancements
|
||||
- AI-powered rule recommendations
|
||||
- Additional email provider support
|
||||
- Multi-tenant architecture support
|
||||
- Enhanced email analytics and reporting
|
||||
|
||||
## Error Handling
|
||||
|
||||
|
||||
Reference in New Issue
Block a user