docs: update documentation to reflect module completion and testing progress
Updated `PROJECT_STATUS.md` with completed modules (`auth`, `groups`, `tags`) and unit testing progress, including marked tests for controllers and services as done. Added logical and conceptual database models (`DATABASE_SCHEMA_PLAN.md`) and revised implementation statuses in `IMPLEMENTATION_GUIDE.md`.
This commit is contained in:
parent
2de57e6e6f
commit
cf292de428
@ -32,11 +32,15 @@ Pour une implémentation efficace, nous recommandons de suivre l'ordre suivant :
|
||||
4. Configurer les guards et décorateurs pour la protection des routes
|
||||
|
||||
### Phase 3 : Modules Principaux
|
||||
1. Implémenter le module projets
|
||||
2. Implémenter le module personnes
|
||||
3. Implémenter le module groupes
|
||||
4. Implémenter le module tags
|
||||
5. Établir les relations entre les modules
|
||||
1. Implémenter le module projets ✅
|
||||
2. Implémenter le module personnes ✅
|
||||
3. Implémenter le module groupes ✅
|
||||
4. Implémenter le module tags ✅
|
||||
5. Établir les relations entre les modules ✅
|
||||
- Relations PersonToGroup ✅
|
||||
- Relations PersonToTag ✅
|
||||
- Relations ProjectToTag ✅
|
||||
- Relations ProjectCollaborators ✅
|
||||
|
||||
### Phase 4 : Communication en Temps Réel
|
||||
1. Configurer Socket.IO avec NestJS
|
||||
|
@ -22,19 +22,21 @@ Nous avons élaboré un plan de bataille complet pour l'implémentation du backe
|
||||
|
||||
#### Composants En Cours
|
||||
- ⏳ Relations entre les modules existants
|
||||
- ⏳ Tests unitaires et e2e
|
||||
|
||||
#### Composants Récemment Implémentés
|
||||
- ✅ Système de migrations de base de données avec DrizzleORM
|
||||
- ✅ Tests unitaires pour les modules auth, groups et tags
|
||||
|
||||
#### Composants Non Implémentés
|
||||
- ⏳ Module d'authentification avec GitHub OAuth
|
||||
- ⏳ Stratégies JWT pour la gestion des sessions
|
||||
- ✅ Module d'authentification avec GitHub OAuth
|
||||
- ✅ Stratégies JWT pour la gestion des sessions
|
||||
- ✅ Guards et décorateurs pour la protection des routes
|
||||
- ✅ Module groupes
|
||||
- ✅ Module tags
|
||||
- ❌ Communication en temps réel avec Socket.IO
|
||||
- ❌ Fonctionnalités de conformité RGPD
|
||||
- ⏳ Tests unitaires et e2e
|
||||
- ❌ Tests e2e complets
|
||||
- ❌ Documentation API avec Swagger
|
||||
|
||||
### Frontend
|
||||
@ -74,7 +76,15 @@ Nous avons élaboré un plan de bataille complet pour l'implémentation du backe
|
||||
##### Modules Manquants
|
||||
- [x] Implémenter le module groupes (contrôleurs, services, DTOs)
|
||||
- [x] Implémenter le module tags (contrôleurs, services, DTOs)
|
||||
- [ ] Compléter les relations entre les modules existants
|
||||
- [x] Compléter les relations entre les modules existants
|
||||
|
||||
##### Tests Unitaires
|
||||
- [x] Écrire des tests unitaires pour le module auth
|
||||
- [x] Écrire des tests unitaires pour le module groups
|
||||
- [x] Écrire des tests unitaires pour le module tags
|
||||
- [x] Écrire des tests unitaires pour le module persons
|
||||
- [x] Écrire des tests unitaires pour le module projects
|
||||
- [x] Écrire des tests unitaires pour le module users
|
||||
|
||||
#### Priorité Moyenne
|
||||
|
||||
@ -95,8 +105,9 @@ Nous avons élaboré un plan de bataille complet pour l'implémentation du backe
|
||||
#### Priorité Basse
|
||||
|
||||
##### Tests et Documentation
|
||||
- [x] Écrire des tests unitaires pour les services
|
||||
- [x] Écrire des tests unitaires pour les contrôleurs
|
||||
- [x] Écrire des tests unitaires pour les services (tous les modules)
|
||||
- [x] Écrire des tests unitaires pour les contrôleurs (tous les modules)
|
||||
- [x] Écrire des tests unitaires pour tous les modules
|
||||
- [ ] Développer des tests e2e pour les API
|
||||
- [ ] Configurer Swagger pour la documentation API
|
||||
- [ ] Documenter les endpoints API
|
||||
@ -172,7 +183,7 @@ Nous avons élaboré un plan de bataille complet pour l'implémentation du backe
|
||||
2. **Modules et Relations**
|
||||
- ✅ Implémenter le module groupes
|
||||
- ✅ Implémenter le module tags
|
||||
- Compléter les relations entre les modules existants
|
||||
- ✅ Compléter les relations entre les modules existants
|
||||
|
||||
### Frontend (Priorité Haute)
|
||||
1. **Authentification**
|
||||
@ -194,7 +205,7 @@ Nous avons élaboré un plan de bataille complet pour l'implémentation du backe
|
||||
| Backend - Modules Fonctionnels | 80% |
|
||||
| Backend - Authentification | 90% |
|
||||
| Backend - WebSockets | 0% |
|
||||
| Backend - Tests et Documentation | 40% |
|
||||
| Backend - Tests et Documentation | 70% |
|
||||
| Frontend - Structure de Base | 70% |
|
||||
| Frontend - Pages et Composants | 10% |
|
||||
| Frontend - Authentification | 0% |
|
||||
|
@ -11,6 +11,172 @@ Le schéma de base de données est conçu pour supporter les fonctionnalités su
|
||||
- Création et gestion de groupes
|
||||
- Système de tags pour catégoriser les personnes et les projets
|
||||
|
||||
### 1.1 Modèle Conceptuel de Données (MCD)
|
||||
|
||||
Le MCD représente les entités principales et leurs relations à un niveau conceptuel.
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
USER ||--o{ PROJECT : "possède"
|
||||
USER ||--o{ PROJECT_COLLABORATOR : "collabore sur"
|
||||
PROJECT ||--o{ PERSON : "contient"
|
||||
PROJECT ||--o{ GROUP : "organise"
|
||||
PROJECT ||--o{ PROJECT_COLLABORATOR : "a des collaborateurs"
|
||||
PROJECT }o--o{ TAG : "est catégorisé par"
|
||||
PERSON }o--o{ GROUP : "appartient à"
|
||||
PERSON }o--o{ TAG : "est catégorisé par"
|
||||
|
||||
USER {
|
||||
uuid id PK
|
||||
string githubId
|
||||
string name
|
||||
string avatar
|
||||
string role
|
||||
datetime gdprTimestamp
|
||||
}
|
||||
|
||||
PROJECT {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
json settings
|
||||
uuid ownerId FK
|
||||
boolean isPublic
|
||||
}
|
||||
|
||||
PERSON {
|
||||
uuid id PK
|
||||
string name
|
||||
string email
|
||||
int technicalLevel
|
||||
string gender
|
||||
json attributes
|
||||
uuid projectId FK
|
||||
}
|
||||
|
||||
GROUP {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
json settings
|
||||
uuid projectId FK
|
||||
}
|
||||
|
||||
TAG {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
string color
|
||||
enum type
|
||||
}
|
||||
|
||||
PROJECT_COLLABORATOR {
|
||||
uuid projectId FK
|
||||
uuid userId FK
|
||||
}
|
||||
```
|
||||
|
||||
### 1.2 Modèle Logique de Données (MLD)
|
||||
|
||||
Le MLD représente la structure de la base de données avec toutes les tables, y compris les tables de jonction pour les relations many-to-many.
|
||||
|
||||
```mermaid
|
||||
erDiagram
|
||||
users ||--o{ projects : "owns"
|
||||
users ||--o{ project_collaborators : "collaborates on"
|
||||
projects ||--o{ persons : "contains"
|
||||
projects ||--o{ groups : "organizes"
|
||||
projects ||--o{ project_collaborators : "has collaborators"
|
||||
projects ||--o{ project_to_tag : "is categorized by"
|
||||
persons ||--o{ person_to_group : "belongs to"
|
||||
persons ||--o{ person_to_tag : "is categorized by"
|
||||
groups ||--o{ person_to_group : "contains"
|
||||
tags ||--o{ person_to_tag : "categorizes"
|
||||
tags ||--o{ project_to_tag : "categorizes"
|
||||
|
||||
users {
|
||||
uuid id PK
|
||||
string github_id
|
||||
string name
|
||||
string avatar
|
||||
string role
|
||||
datetime gdpr_timestamp
|
||||
datetime created_at
|
||||
datetime updated_at
|
||||
}
|
||||
|
||||
projects {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
json settings
|
||||
uuid owner_id FK
|
||||
boolean is_public
|
||||
datetime created_at
|
||||
datetime updated_at
|
||||
}
|
||||
|
||||
persons {
|
||||
uuid id PK
|
||||
string name
|
||||
string email
|
||||
int technical_level
|
||||
string gender
|
||||
json attributes
|
||||
uuid project_id FK
|
||||
datetime created_at
|
||||
datetime updated_at
|
||||
}
|
||||
|
||||
groups {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
json settings
|
||||
uuid project_id FK
|
||||
datetime created_at
|
||||
datetime updated_at
|
||||
}
|
||||
|
||||
tags {
|
||||
uuid id PK
|
||||
string name
|
||||
string description
|
||||
string color
|
||||
enum type
|
||||
datetime created_at
|
||||
datetime updated_at
|
||||
}
|
||||
|
||||
person_to_group {
|
||||
uuid id PK
|
||||
uuid person_id FK
|
||||
uuid group_id FK
|
||||
datetime created_at
|
||||
}
|
||||
|
||||
person_to_tag {
|
||||
uuid id PK
|
||||
uuid person_id FK
|
||||
uuid tag_id FK
|
||||
datetime created_at
|
||||
}
|
||||
|
||||
project_to_tag {
|
||||
uuid id PK
|
||||
uuid project_id FK
|
||||
uuid tag_id FK
|
||||
datetime created_at
|
||||
}
|
||||
|
||||
project_collaborators {
|
||||
uuid id PK
|
||||
uuid project_id FK
|
||||
uuid user_id FK
|
||||
datetime created_at
|
||||
}
|
||||
```
|
||||
|
||||
## 2. Tables Principales
|
||||
|
||||
### 2.1 Table `users`
|
||||
|
Loading…
x
Reference in New Issue
Block a user