[NEW] maintenance_service_http_monitoring: create add-on

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

@@ -0,0 +1,92 @@
+# Draft: Monitoring HTTP des services
+
+## Contexte codebase
+
+### Architecture des modules
+```
+maintenance_server_data (base, maintenance)
+├── Définit: service, service.version, service.instance, backup.server
+├── Extend maintenance.equipment: server_ip, service_ids (One2many), backup_*, etc.
+└── Vues: service list, equipment form (onglet Services)
+
+maintenance_server_ssh (base, maintenance)
+├── Extend maintenance.equipment: server_domain, ssh_private_key_path
+└── Méthode: get_ssh_connection()
+
+maintenance_server_monitoring (base, maintenance, maintenance_server_ssh)
+├── Extend maintenance.equipment: monitoring fields + test methods
+├── Pattern MonitoringTest inner class (test_ok/warning/error)
+├── Cron: toutes les 1 minute sur ALL equipment
+├── Création auto de maintenance.request si error/warning
+└── PAS de dépendance vers maintenance_server_data actuellement !
+```
+
+### 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
+- 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] 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`
+
+## 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
+- Cron dédié pour les checks HTTP (fréquence configurable)
+- _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
+
+## 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)
+- Paramètres module (fréquence + durée mode maintenance)
+- Mode maintenance sur equipment (bool tracked, bandeau, HTTP checks only)
+- Création maintenance.request si service KO (référence sur equipment)
+- Nouvelle vue liste services avec colonnes monitoring
+- 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
+- Pas de tracking sur service.instance (pas de mail.thread sur ce modèle)
+
+## 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)
+- `requests` library: Déclarer dans external_dependencies.python
+- Chaque requests.get() DOIT avoir timeout= (pylintrc enforce external-request-timeout)