[IMP] maintenance_project_task_domain, maintenance_server_data, maintenance_service_http_monitoring, maintenance_create_requests_from_project_task: pre-commit execution

maintenance_service_http_monitoring/DEV/.sisyphus/drafts/service-http-monitoring.md

@@ -3,6 +3,7 @@
 ## Contexte codebase
 
 ### Architecture des modules
+
 ```
 maintenance_server_data (base, maintenance)
 ├── Définit: service, service.version, service.instance, backup.server
@@ -22,51 +23,64 @@ maintenance_server_monitoring (base, maintenance, maintenance_server_ssh)
 ```
 
 ### Modèle service.instance actuel (dans maintenance_server_data)
+
 - equipment_id (Many2one → maintenance.equipment)
 - service_id (Many2one → service, required)
 - version_id (Many2one → service.version)
 - service_url (Char) ← URL déjà existante, parfait pour les checks HTTP
 
 ### Pattern de création maintenance.request existant
+
 - Vérifie si une request non-done existe déjà avant d'en créer une nouvelle
-- Stocke la référence sur equipment: error_maintenance_request / warning_maintenance_request
+- Stocke la référence sur equipment: error_maintenance_request /
+  warning_maintenance_request
 - Assignation auto: employee_id, technician_user_id, maintenance_team_id
 
 ## Requirements confirmés (depuis les specs)
 
 - [x] Modifier le module `maintenance_server_monitoring` (pas de nouveau module)
-- [x] Ajouter `maintenance_server_data` aux dépendances (nécessaire pour accéder à service.instance)
-- [x] Étendre `service.instance` avec: last_status_code (Integer), last_check_date (Datetime), status OK/KO (Boolean)
-- [x] Nouvelle vue liste standalone pour service.instance (nom, version, URL, date check, status code, statut)
+- [x] Ajouter `maintenance_server_data` aux dépendances (nécessaire pour accéder à
+      service.instance)
+- [x] Étendre `service.instance` avec: last_status_code (Integer), last_check_date
+      (Datetime), status OK/KO (Boolean)
+- [x] Nouvelle vue liste standalone pour service.instance (nom, version, URL, date
+      check, status code, statut)
 - [x] Paramètres module: fréquence vérification + durée mode maintenance
 - [x] Mode maintenance sur equipment: bool tracked + bandeau
 - [x] Si service KO → création maintenance.request (pas de doublon si toujours KO)
 
 ## Décision architecturale : NOUVEAU MODULE
 
-**Nom**: `maintenance_service_http_monitoring`
-**Raison**: Séparation des préoccupations — monitoring infra (SSH/ping) vs monitoring applicatif (HTTP)
-**Dépendances**: `base`, `maintenance`, `maintenance_server_data`
-**PAS de dépendance** vers `maintenance_server_ssh` ni `maintenance_server_monitoring`
+**Nom**: `maintenance_service_http_monitoring` **Raison**: Séparation des préoccupations
+— monitoring infra (SSH/ping) vs monitoring applicatif (HTTP) **Dépendances**: `base`,
+`maintenance`, `maintenance_server_data` **PAS de dépendance** vers
+`maintenance_server_ssh` ni `maintenance_server_monitoring`
 
 ## Décisions techniques
 
 - Paramètres via res.config.settings + ir.config_parameter (pattern standard Odoo)
-- _inherit = 'service.instance' dans le nouveau module pour étendre le modèle
+- \_inherit = 'service.instance' dans le nouveau module pour étendre le modèle
 - Cron dédié pour les checks HTTP (fréquence configurable)
-- _inherit = 'maintenance.equipment' pour ajouter maintenance_mode + http_maintenance_request
+- \_inherit = 'maintenance.equipment' pour ajouter maintenance_mode +
+  http_maintenance_request
 - mail.thread déjà hérité par maintenance.equipment dans Odoo base → tracking fonctionne
 
 ## Décisions utilisateur (interview)
 
-1. **Mode maintenance**: HTTP uniquement — le monitoring existant (ping, SSH, mémoire, disque) continue normalement
-2. **Lien maintenance.request**: Sur maintenance.equipment — nouveau champ `http_maintenance_request` (Many2one). Si plusieurs services KO sur un même equipment, UNE seule request qui liste les services KO.
-3. **Menu service list**: Sous Maintenance > principal, même niveau que Équipements et Demandes
-4. **Tests**: OUI — setup pytest-odoo + tests unitaires pour la logique HTTP check et création maintenance requests
+1. **Mode maintenance**: HTTP uniquement — le monitoring existant (ping, SSH, mémoire,
+   disque) continue normalement
+2. **Lien maintenance.request**: Sur maintenance.equipment — nouveau champ
+   `http_maintenance_request` (Many2one). Si plusieurs services KO sur un même
+   equipment, UNE seule request qui liste les services KO.
+3. **Menu service list**: Sous Maintenance > principal, même niveau que Équipements et
+   Demandes
+4. **Tests**: OUI — setup pytest-odoo + tests unitaires pour la logique HTTP check et
+   création maintenance requests
 
 ## Scope boundaries
 
 ### IN
+
 - NOUVEAU module `maintenance_service_http_monitoring`
 - Étendre service.instance avec champs monitoring HTTP
 - Cron dédié pour checks HTTP (fréquence configurable)
@@ -77,6 +91,7 @@ maintenance_server_monitoring (base, maintenance, maintenance_server_ssh)
 - Setup pytest-odoo + tests unitaires
 
 ### OUT
+
 - Aucune modification de `maintenance_server_monitoring` ni de `maintenance_server_ssh`
 - Pas de notification email (juste la maintenance.request)
 - Pas de dashboard / reporting
@@ -84,9 +99,13 @@ maintenance_server_monitoring (base, maintenance, maintenance_server_ssh)
 
 ## Décisions Metis (post-gap-analysis)
 
-- Services orphelins (sans equipment_id): N'existent pas en pratique, filtrés par sécurité
-- Récupération service KO→OK: Rien d'automatique, close manuelle de la maintenance.request
-- Définition KO: Tout échec = KO (timeout, DNS, SSL, connexion refusée, code != 200). Log le détail.
-- Timeout HTTP: Hardcodé (constante, comme les seuils existants dans maintenance_server_monitoring)
+- Services orphelins (sans equipment_id): N'existent pas en pratique, filtrés par
+  sécurité
+- Récupération service KO→OK: Rien d'automatique, close manuelle de la
+  maintenance.request
+- Définition KO: Tout échec = KO (timeout, DNS, SSL, connexion refusée, code != 200).
+  Log le détail.
+- Timeout HTTP: Hardcodé (constante, comme les seuils existants dans
+  maintenance_server_monitoring)
 - `requests` library: Déclarer dans external_dependencies.python
 - Chaque requests.get() DOIT avoir timeout= (pylintrc enforce external-request-timeout)