@ -4,87 +4,54 @@ A WhatsApp chatbot for task management, designed to work with Evolution API in a
## 📌 Overview
This service provides a WhatsApp interface for task management within WhatsApp groups. It:
- Listens for `/tarea` commands in WhatsApp groups via Evolution API webhooks.
- Stores tasks, users, and groups in a SQLite database.
- Synchronizes group information periodically from the Evolution API.
- Manages user permissions and group membership (partially implemented).
- Integrates with Evolution API for WhatsApp connectivity.
- Listens for `/tarea` commands in WhatsApp groups
- Stores tasks in a SQLite database
- Manages user permissions and group membership
- Integrates with Evolution API for WhatsApp connectivity
## 🔐 Security Model
- **Internal Networking**: The webhook should ideally only accept connections from Evolution API via internal Docker networking (configuration dependent).
- **Environment Variables**: Sensitive configuration (API keys, URLs) is managed through environment variables.
- **Group Restrictions**: Designed to operate within pre-approved WhatsApp groups (validation logic pending implementation).
- **Input Validation**: Basic validation exists for webhook structure; needs enhancement for command arguments and user/group IDs.
- **Internal Networking**: The webhook only accepts connections from Evolution API via internal Docker networking
- **Environment Variables**: Sensitive configuration is managed through environment variables
- **Group Restrictions**: Only operates within pre-approved WhatsApp groups
- **Input Validation**: Sanitizes and validates all user inputs
## 🧱 Architecture
```mermaid
graph TD
A[Webhook Received] --> B{Valid Payload?}
B -->|No| C[Ignore]
B -->|Yes| D{Normalize IDs & Check Group Active?}
D -->|No| C[Ignore/Log]
D -->|Yes| E[Ensure User Exists in DB]
B -->|Yes| D{From Known Group?}
D -->|Yes| E[Update User Last Seen]
D -->|No| F{Private Chat + Known User?}
F -->|No| C
F -->|Yes| E
E --> G{/tarea Command?}
G -->|No| C
G -->|Yes| J[Process Command Logic]
J -- Success/Error --> K[Queue Response(s)]
K --> L[Process Queue & Send Response via API]
subgraph Database Interaction
E --> DB[(SQLite DB)]
J --> DB
end
subgraph Evolution API
L --> EA((Evolution API))
EA -- Webhook --> A
end
G -->|Yes| H{New User?}
H -->|Yes| I[Add to DB]
H -->|No| J[Process Command]
```
*(Diagram updated for planned flow)*
## ✅ Current Status (as of commit dd32a3d)
### Implemented
- Webhook server setup (`src/server.ts`) receiving Evolution API events.
- Database schema definition and initialization (`src/db.ts`).
- Group synchronization service (`src/services/group-sync.ts`) to fetch/store/cache groups.
- Webhook registration and verification with Evolution API (`src/services/webhook-manager.ts`).
- Basic `/tarea` command detection and argument parsing structure (`src/server.ts`).
- Task data models (`src/tasks/model.ts`).
- Basic task creation service stub (`src/tasks/service.ts` - needs `created_by` and assignment logic).
- Response queue structure (`src/services/response-queue.ts` - `process` method is empty).
- Unit testing setup with in-memory database (`tests/`).
- **User/Group Validation:** No normalization of WhatsApp IDs or checking if messages originate from active, known groups. Users are not automatically added to the DB.
- **Core Command Logic:** Actual processing of `/tarea nueva` (parsing args, calling `TaskService`) is missing in `CommandService`. Other commands (`mostrar`, `completar`) not implemented.
- **Task Service Implementation:**`TaskService` needs updating to handle `created_by`, assignments, and potentially methods for listing/completing tasks.
- **Response Sending:**`ResponseQueue` does not yet send messages back via the Evolution API.
- **Database Migrations:** No system in place to manage schema changes.
- **Robust Error Handling:** Comprehensive error handling, logging, and transaction management need improvement, especially around API calls and DB operations.
* **WhatsApp ID Normalization:** Crucial for consistently identifying users and groups. Needs careful implementation to handle edge cases.
* **Response Latency:** Sending responses requires an API call back to Evolution. Ensure the `ResponseQueue` processing is efficient.
* **Group Sync:** The current full sync might be slow or rate-limited with many groups. Delta updates are recommended long-term.
* **Error Handling:** Failures in command processing or response sending should be logged clearly and potentially reported back to the user. Database operations should use transactions for atomicity (especially task+assignment creation).
* **State Management:** The current design is stateless. Complex interactions might require state persistence later.
* **Security:** Ensure group/user validation logic is robust.
## 📅 Roadmap
### High Priority
- [ ] Implement ResponseQueue processing logic with retries
- [ ] Add database schema validation and migrations
- [ ] Add error recovery with transaction rollback
- [ ] Implement group sync delta updates
### Medium Priority
- [ ] Add task assignment and ownership
- [ ] Implement user permissions system
- [ ] Add rate limiting for API calls
- [ ] Create task history tracking
### Low Priority
- [ ] Add task reminders system
- [ ] Implement multi-language support
- [ ] Create analytics dashboard
- [ ] Add user-friendly task list UI
## 🧪 Testing
### Running Tests
@ -146,19 +92,17 @@ bun test
```
### Test Coverage
- Database initialization and basic operations.
- Webhook validation (basic).
- Command parsing (basic structure).
- Environment checks.
- Basic error handling.
- **Needed:** Tests for ID normalization, `ensureUserExists`, `isGroupActive`, `CommandService` logic, `ResponseQueue` processing (mocking API), `TaskService` operations.
- Webhook validation
- Command parsing
- Environment checks
- Basic error handling
- Input validation
## 🧑💻 Contributing
1. Fork the repository
2. Create a feature branch (`git checkout -b feature/implement-user-validation`)
3. Add/update tests for new functionality
4. Ensure tests pass (`bun test`)
5. Submit a pull request
2. Create a feature branch
3. Add tests for new functionality
4. Submit a pull request
## 📚 Documentation
For detailed API documentation and architecture decisions, see the [docs/](docs/) directory (if created).
For detailed API documentation and architecture decisions, see the [docs/](docs/) directory.