update docs.

This commit is contained in:
Bryce
2025-08-09 21:04:21 -07:00
parent af637f29b4
commit d6635a42df
7 changed files with 484 additions and 86 deletions

View File

@@ -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