Tâches d'amélioration — csv-to-timemanager.py

Validation des champs obligatoires

TODO : Améliorer la validation des champs CSV

Actuellement : le script n'effectue pas de validation stricte sur les champs obligatoires. Cela peut conduire à :

Créer des tâches avec un nom vide (si Titre manque).
Créer des entrées de temps avec start ou end incomplets (si dates/heures manquent).

À faire :

Ajouter une validation au début de la boucle de traitement des lignes CSV pour vérifier que les champs suivants sont non-vides et valides :
- Titre : non vide après nettoyage.
- Date debut : non vide et correspond à un format date valide.
- Heure debut : non vide et correspond à un format heure valide (ex: HH:MM ou HH:MM:SS).
- Date fin : non vide et correspond à un format date valide.
- Heure fin : non vide et correspond à un format heure valide.
Condition d'import : une ligne est importée seulement si :
- Description OU Categories sont renseignés (au moins un),
- ET tous les champs listés ci-dessus sont valides.
Pour les lignes invalides : enregistrer une ligne de log / warning avec la raison (ex: "Titre manquant", "Date debut invalide"), pour faciliter le débogage.

TEST : Vérifier qu'aucune tâche n'est créée avec champs manquants

Objectif : S'assurer que le code corrigé ne crée pas de tâches/entrées de temps incomplètes.

À faire :

Créer un petit fichier CSV de test contenant des lignes avec champs manquants (ex: Titre vide, Date debut manquant, etc.).
Exécuter le script avec ce fichier de test.
Vérifier dans la base de données ou via l'interface TimeManager que aucune tâche ou entrée de temps incomplète n'a été créée.
Documenter les résultats du test dans un fichier tests/csv_validation_test.md.

Alternative : Utiliser la validation existante dans TimeManager

Si l'API TimeManager rejette les entrées incomplètes, le script bénéficiera indirectement de cette validation. À vérifier auprès du serveur TimeManager (réponse HTTP 406 / erreur de validation de la requête).

Gestion des modifications utilisateur et réimport

TODO : Analyser le comportement en cas de modification manuelle + réimport

Problème : Que se passe-t-il si un utilisateur modifie une tâche ou une entrée de temps directement dans TimeManager, puis que le script réimporte le même CSV ?

Cas d'usage :

Un CSV est importé, créant une tâche Nom original avec une entrée de temps.
L'utilisateur renomme la tâche à Nom modifié dans TimeManager.
Le CSV est réimporté avec la même ligne.

Comportement actuel :

Le script utilise la colonne Titre du CSV (ex: Nom original) pour chercher la tâche existante.
Si la tâche a été renommée (ex: Nom modifié), le script ne la trouvera pas (car sanitize("Nom original") != sanitize("Nom modifié")).
Le script créera une nouvelle tâche Nom original, créant ainsi un doublon.
L'ancienne tâche (Nom modifié) restera en place dans TimeManager.

Risques :

Création involontaire de doublons.
Incohérence entre le CSV et TimeManager.
Perte de données si les modifications de l'utilisateur n'ont pas été sauvegardées ailleurs.

À considérer :

Faut-il implémenter une stratégie de fusionnement / synchronisation bidirectionnelle (ex: tracking des UUIDs) ?
Faut-il documenter que le script n'est pas conçu pour gérer les modifications manuelles post-import ?
Faut-il ajouter une option --allow-duplicates ou --force-sync au script pour expliciter ce comportement ?
Analyser comment l'app TimeManager gère les commits et les conflits (voir lib/Db/StorageHelper.php).

Priorité : À discuter avec l'équipe pour clarifier le flux de travail prévu.

Références

Détail de la validation : voir docs/specs.md section "Gestion des données manquantes".
Code de validation des lignes : voir csv-to-timemanager.py ligne ~437.
Détection d'existence de tâches : voir csv-to-timemanager.py fonctions task_exist_by_name, project_exist_by_name, client_exist_by_name.
Stratégie de sync TimeManager : voir lib/Db/StorageHelper.php (analyse du système de commits et résolution de conflits).

4.4 KiB Raw Blame History