Implémente un système de marquage de priorité pour les tâches avec une
icône étoile cliquable.
Fonctionnalités ajoutées :
- Champ priority (BOOLEAN) ajouté aux tables global_todos et note_todos
- Migration automatique avec script add-priority-field.js
- Route API PATCH /api/todos/:id/priority pour basculer la priorité
- Icône étoile (Star) dans l'interface frontend
- Tri automatique : tâches prioritaires en premier
- Index PostgreSQL pour optimiser les performances
Comportement de l'icône :
- Toujours visible et jaune quand la tâche est prioritaire
- Visible au survol (hover) quand la tâche n'est pas prioritaire
- Un clic bascule l'état prioritaire/non prioritaire
- Affichage discret (opacity 50%) pour les tâches complétées
Scripts npm ajoutés :
- npm run db:migrate:priority - Exécuter la migration
Routes API mises à jour :
- GET /api/todos - Inclut le champ priority, tri par priorité
- POST /api/todos - Accepte le champ priority
- PUT /api/todos/:id - Accepte le champ priority
- PATCH /api/todos/:id/priority - Bascule la priorité (nouveau)
UI améliorée :
- Icône étoile jaune pour les tâches prioritaires
- Animation au survol pour les interactions
- Tooltip explicatif au survol
- Onglets "Actives" et "Complétées" mis à jour
Implémente un système complet de purge automatique pour maintenir
la base de données propre et performante.
Fonctionnalités ajoutées :
- Migration pour ajouter les champs de tracking (archived_at, completed_at)
- Triggers PostgreSQL pour mise à jour automatique des dates
- Script de purge manuel avec mode simulation (dry-run)
- Scheduler automatique configurable (défaut: 24h)
- Routes API admin pour contrôle et monitoring
- Documentation complète
Éléments purgés :
- Flux RSS désactivés (tous)
- Tâches complétées > 3 mois (configurable)
- Notes archivées > 6 mois (configurable)
- Rendez-vous passés > 6 mois (configurable)
Scripts npm ajoutés :
- npm run db:migrate - Exécuter la migration
- npm run db:cleanup - Purge manuelle
- npm run db:cleanup:dry-run - Simulation de purge
Routes API ajoutées :
- POST /api/admin/cleanup - Déclencher la purge
- GET /api/admin/cleanup/preview - Prévisualiser la purge
- GET /api/admin/cleanup/status - Statut du scheduler
- GET /api/admin/stats - Statistiques DB
Configuration via variables d'environnement :
- CLEANUP_ENABLED (défaut: true)
- CLEANUP_INTERVAL_HOURS (défaut: 24)
- CLEANUP_COMPLETED_TASKS_DAYS (défaut: 90)
- CLEANUP_ARCHIVED_NOTES_DAYS (défaut: 180)
- CLEANUP_PAST_EVENTS_DAYS (défaut: 180)
- Création de 3 composants UI mobile réutilisables (MobileHeader, MobileFAB, MobileCard)
- Création du layout MobileDashboard avec sidebar navigation
- Implémentation de 6 pages mobiles :
* CalendarPage : gestion des événements avec pagination
* NotesPage : liste des notes avec recherche et filtres
* NoteDetailPage : édition complète de notes en fullscreen
* TodosPage : gestion des tâches actives/complétées
* RssPage : affichage des flux RSS avec actualisation
* SettingsPage : paramètres de l'application
- Configuration du routing automatique mobile/desktop dans App.tsx
- Détection automatique du device avec redirection intelligente
- Tous les services backend réutilisés sans modification
- Build testé et fonctionnel
Problème :
- Après modification d'une note, il fallait rafraîchir la page pour voir updated_at
- Après ajout d'un tag, il fallait rafraîchir la page pour le voir dans la note
Solution backend :
1. routes/notes.routes.js - PUT /api/notes/:id :
- Récupération de la note mise à jour après UPDATE
- Retour de { message, note } au lieu de juste { message }
- La note retournée contient la vraie updated_at générée par PostgreSQL
Solution frontend :
1. NotesService.ts - updateNote() :
- Changement du type de retour de Promise<boolean> vers Promise<Note | null>
- Récupération et retour de la note mise à jour depuis la réponse du serveur
- Merge de la note locale (todos, images) avec les données du serveur (updated_at)
2. Index.tsx - handleNoteChange et handleContentChange :
- Utilisation de la note retournée par updateNote() au lieu de l'état local
- Mise à jour de openNote et notes avec les données du serveur
3. Index.tsx - Synchronisation des tags :
- loadNoteTags : Mise à jour de openNote.tags après chargement
- confirmAddTag : Mise à jour de openNote.tags après ajout
- handleDeleteTag : Mise à jour de openNote.tags après suppression
- Conversion du format { id, tag } vers { id, name } pour cohérence
Résultat :
- Les dates de modification s'affichent immédiatement après sauvegarde
- Les tags ajoutés apparaissent immédiatement dans l'interface
- Plus besoin de rafraîchir la page manuellement
Problème identifié :
- Quand une nouvelle note était créée, elle écrasait la première note existante
- La fonction runQuery() dans database-postgres.js retournait rowCount (1) au lieu de l'ID réel
- Les requêtes INSERT n'utilisaient pas RETURNING pour récupérer l'ID généré
Solution implémentée :
1. Ajout de RETURNING * à toutes les requêtes INSERT dans :
- routes/notes.routes.js (notes, todos, images, fichiers, tags)
- routes/todos.routes.js (todos globaux)
- routes/users.routes.js (utilisateurs)
- routes/rss.routes.js (flux RSS, résumés)
- routes/settings.routes.js (paramètres)
- routes/calendar.routes.js (événements, tokens OAuth)
2. Modification de runQuery() pour :
- Retourner la ligne complète si RETURNING est présent
- Inclure tous les champs de la ligne insérée (spread operator)
- Ajouter des logs détaillés pour le debugging
3. Ajout de logs détaillés pour tracer :
- Chaque création d'entité avec ses paramètres
- L'ID retourné après insertion
- Les erreurs potentielles
Impact :
- Les nouvelles notes ont maintenant leur vrai ID auto-incrémenté
- Plus d'écrasement des notes existantes
- Meilleure traçabilité avec les logs détaillés
Problème identifié:
- Google Calendar envoie '2025-11-17T10:20:00+01:00' (10h20 Paris = 09h20 UTC)
- PostgreSQL TIMESTAMP enlève le fuseau horaire et stocke '2025-11-17 10:20:00' (heure locale)
- Le parser 1114 traite cette valeur comme UTC → '2025-11-17T10:20:00.000Z'
- Frontend affiche 11h20 en heure de Paris (10:20 UTC + 1h) au lieu de 10h20
Solution:
- Convertir tous les timestamps en UTC (ISO format) avant insertion dans PostgreSQL
- Appliquer la conversion dans toutes les routes: POST /sync, POST /events, PUT /events/:id
- Le parser 1114 traite maintenant correctement les valeurs UTC stockées
Changements:
- routes/calendar.routes.js: Conversion UTC avant insertion (3 routes corrigées)
- routes/calendar.routes.js: Correction syntaxe PostgreSQL (INSERT ... ON CONFLICT)
- scripts/cleanup-calendar-events.js: Script pour nettoyer les événements existants
Pour appliquer la correction sur les données existantes:
1. Exécuter: docker exec notes-todo-app node scripts/cleanup-calendar-events.js
2. Redémarrer: docker-compose restart notes-app
3. Resynchroniser Google Calendar depuis l'interface web
NOUVEAU SYSTÈME DE LOGGING:
Au lieu d'utiliser les logs Docker (inaccessibles depuis Portainer),
création d'un système de logs accessible directement dans le navigateur.
FICHIERS AJOUTÉS:
1. services/timezone-logger.js:
- Service singleton qui stocke les logs en mémoire
- Limite à 500 logs max (pour éviter les fuites mémoire)
- Méthodes: log(), getLogs(), clearLogs(), getLogsByCategory()
2. routes/timezone-logs.routes.js:
- GET /api/timezone-logs - Logs en JSON
- GET /api/timezone-logs/html - Interface web avec design moderne
- GET /api/timezone-logs/category/:cat - Filtrer par catégorie
- POST /api/timezone-logs/clear - Vider les logs
3. VOIR-LOGS-TIMEZONE.md:
- Documentation complète du système
- Procédure pas à pas
- Explications des logs attendus
FICHIERS MODIFIÉS:
1. config/database.js:
- Utilise timezoneLogger au lieu de logger.debug
- Catégorie: PARSER
2. routes/calendar.routes.js:
- Logs avec timezoneLogger lors de la synchronisation
- Catégorie: SYNC (synchronisation Google Calendar)
- Catégorie: GET (envoi au frontend)
3. server.js:
- Ajout de la route /api/timezone-logs
INTERFACE WEB DE LOGS:
Accessible sur: http://localhost:2222/api/timezone-logs/html
Fonctionnalités:
- ✅ Design moderne avec dégradés et animations
- ✅ Statistiques en temps réel (total, par catégorie)
- ✅ Filtrage par catégorie (SYNC, PARSER, GET)
- ✅ Auto-refresh toutes les 3 secondes
- ✅ Code couleur par catégorie
- ✅ Affichage des données JSON formatées
- ✅ Bouton pour vider les logs
- ✅ Responsive, fonctionne sur mobile
UTILISATION:
1. Rebuild: docker-compose build --no-cache notes-app
2. Ouvrir: http://localhost:2222/api/timezone-logs/html
3. Synchroniser Google Calendar
4. Observer les logs en temps réel dans le navigateur
Plus besoin d'accès aux logs Docker/Portainer !
Ajout d'un système de logging exhaustif pour tracer le flux complet
des dates depuis Google Calendar jusqu'à l'affichage dans NoteFlow.
FICHIERS MODIFIÉS:
1. config/database.js:
- Logs détaillés dans le parser TIMESTAMPTZ
- Affiche l'input, la transformation et l'output
- Différencie les dates avec/sans timezone
2. routes/calendar.routes.js:
- Logs lors de la synchronisation Google Calendar
- Affiche ce que Google renvoie (format brut)
- Affiche la conversion en UTC et l'affichage Paris
- Logs lors de la récupération des événements (GET /events)
- Nouvel endpoint GET /api/calendar/debug pour diagnostic complet
3. DEBUG-TIMEZONE-LOGS.md:
- Documentation complète du système de logging
- Procédure étape par étape pour débuguer
- Commandes utiles pour analyser les logs
- Guide d'interprétation des résultats
ENDPOINT DE DIAGNOSTIC AJOUTÉ:
GET /api/calendar/debug renvoie:
- Timezone du serveur Node.js
- Timezone de PostgreSQL
- Un événement exemple avec toutes ses représentations
- Test de parsing complet (input → output → display)
UTILISATION:
1. Rebuild avec: docker-compose build --no-cache notes-app
2. Supprimer les événements: DELETE FROM calendar_events
3. Lancer les logs: docker-compose logs -f notes-app
4. Synchroniser Google Calendar
5. Analyser les logs pour identifier où se produit le décalage
Les logs permettront de voir EXACTEMENT:
- Ce que Google Calendar renvoie
- Comment c'est stocké dans PostgreSQL
- Comment le parser le transforme
- Comment le frontend l'affiche
PROBLÈME IDENTIFIÉ:
Les événements synchronisés depuis Google Calendar s'affichaient avec +1h
de décalage (ex: 10:20 dans Google → 11:20 dans NoteFlow).
CAUSE RACINE:
PostgreSQL renvoyait les TIMESTAMPTZ dans le timezone de sa session
(probablement Europe/Paris) au format "2024-11-17 10:20:00" SANS l'info
de timezone. JavaScript interprétait cette string comme UTC, créant un
décalage lors de l'affichage avec toLocaleTimeString Europe/Paris.
FLUX DU BUG:
1. Google Calendar: "2024-11-17T10:20:00+01:00" (10:20 Paris)
2. PostgreSQL stocke: 09:20 UTC (conversion automatique)
3. PostgreSQL renvoie avec timezone=Europe/Paris: "2024-11-17 10:20:00"
4. JavaScript interprète: 10:20 UTC (car pas de timezone)
5. Affichage Paris: 11:20 (10:20 UTC + 1h) ❌
CORRECTIONS APPORTÉES:
1. config/database.js:
- Ajout de l'option `timezone=UTC` au pool PostgreSQL
- Garantit que toutes les connexions utilisent UTC
- Parser TIMESTAMPTZ amélioré pour normaliser en ISO UTC:
* Détecte les formats avec/sans timezone
* Ajoute 'Z' aux dates sans timezone (car timezone=UTC)
* Renvoie toujours une ISO string UTC propre
2. Scripts de test ajoutés:
- scripts/test-parser.js: Validation du parser (5 tests, tous ✅)
- scripts/debug-sync.js: Debug du flux de synchronisation
FLUX CORRIGÉ:
1. Google Calendar: "2024-11-17T10:20:00+01:00" (10:20 Paris)
2. PostgreSQL stocke: 09:20 UTC
3. PostgreSQL renvoie (timezone=UTC): "2024-11-17 09:20:00"
4. Parser normalise: "2024-11-17T09:20:00.000Z"
5. JavaScript interprète: 09:20 UTC
6. Affichage Paris: 10:20 ✅
RÉSULTAT:
Les heures affichées dans NoteFlow correspondent maintenant exactement
à celles de Google Calendar.
IMPORTANT:
Pour que le fix s'applique aux événements existants, il faut:
1. Redémarrer l'application (pour appliquer timezone=UTC)
2. Resynchroniser avec Google Calendar
PROBLÈME IDENTIFIÉ:
Le backend envoyait des dates ISO UTC à Google Calendar API avec
timeZone: 'Europe/Paris', ce qui causait une double interprétation.
Google interprétait l'heure UTC comme étant l'heure locale de Paris,
créant ainsi un décalage d'1 heure.
CORRECTIONS APPORTÉES:
1. Frontend (src/pages/Index.tsx):
- Réécriture de toParisISO() pour convertir correctement les dates
datetime-local en ISO UTC avec gestion automatique de l'heure d'été/hiver
- Calcul dynamique de l'offset Europe/Paris (+01:00 hiver, +02:00 été)
- Tests de validation confirmant le bon fonctionnement (round-trip OK)
2. Backend (routes/calendar.routes.js):
- Retrait de timeZone: 'Europe/Paris' lors de la création d'événements
- Retrait de timeZone: 'Europe/Paris' lors de la mise à jour d'événements
- Google Calendar API interprète maintenant correctement les ISO UTC
3. Scripts de test ajoutés:
- scripts/test-timezone-functions.js: Validation des conversions
- scripts/diagnose-timezone.js: Diagnostic du flux complet
RÉSULTAT:
Les heures affichées dans NoteFlow sont maintenant identiques à celles
de Google Calendar, sans aucun décalage horaire.
Tests effectués:
✅ Conversion datetime-local → ISO UTC (hiver): 14:30 → 13:30 UTC
✅ Conversion datetime-local → ISO UTC (été): 14:30 → 12:30 UTC
✅ Round-trip: conservation de la valeur d'origine
✅ Affichage correct en Europe/Paris depuis ISO UTC
✅ Compilation réussie
Problèmes corrigés:
- Ajout de fonctions utilitaires toLocalDateTimeString() et toParisISO()
pour gérer correctement les conversions de timezone Europe/Paris
- Correction des valeurs par défaut des champs datetime-local lors de la
création d'événements (utilisaient toISOString().slice() incorrectement)
- Correction des valeurs par défaut lors de l'édition d'événements
- Correction de la soumission des formulaires (création et édition)
pour envoyer les dates ISO correctes avec timezone Europe/Paris
Les dates sont désormais:
1. Affichées correctement en heure Europe/Paris dans les formulaires
2. Converties correctement lors de l'envoi au backend
3. Stockées et récupérées sans décalage horaire
Fichiers modifiés:
- src/pages/Index.tsx: Ajout des fonctions utilitaires et correction
de toutes les conversions de dates pour les événements du calendrier
Problème: Décalage d'1 heure persistant malgré types.setTypeParser
Cause probable: Container pas rebuild avec le fix database.js
Ajouts:
1. scripts/check-calendar-timezone.js
- Diagnostic complet timezone PostgreSQL/Node.js
- Vérifie si types.setTypeParser(1184) fonctionne
- Affiche type de données retourné (string vs Date object)
- Compare valeurs SQL brutes avec valeurs JS
2. CALENDAR_TIMEZONE_FIX.md
- Documentation complète du problème
- Procédure de fix étape par étape
- Explication technique de la cause
- Historique des tentatives
Utilisation:
```bash
# 1. Diagnostic
node scripts/check-calendar-timezone.js
# 2. Si Date object au lieu de string:
docker-compose build --no-cache notes-app
docker-compose up -d
# 3. Resynchroniser calendrier depuis UI
```
Le fix types.setTypeParser(1184) est déjà en place dans database.js
mais nécessite un rebuild du container pour être actif.
Améliorations UX:
1. Message bouton sélecteur adapté selon rôle utilisateur
- Admin: "Configurer clé API OpenRouter"
- Non-admin: "Aucun modèle IA configuré"
2. Popover avec lien direct vers config pour admins
- CommandEmpty affiche message explicatif
- Bouton "Configurer OpenRouter" ouvre Admin → OpenRouter
- Ferme le popover et ouvre directement l'onglet config
Résultat: L'admin peut maintenant configurer OpenRouter en 1 clic depuis le chat
Problème: Les modèles IA ne s'affichaient pas dans l'Assistant IA
- Settings route nécessite requireAdmin (routes/settings.routes.js:10)
- Frontend vérifiait settings.openrouter_api_key avant de charger les modèles
- Utilisateurs non-admin ne peuvent jamais récupérer settings
- Donc openRouterModels restait toujours vide []
Solution:
- Suppression du check settings.openrouter_api_key (Index.tsx:557,263)
- Le backend retourne déjà [] si clé API non configurée (fix précédent)
- Tous les utilisateurs peuvent maintenant charger les modèles IA
Note: L'admin doit configurer la clé API OpenRouter dans Admin → OpenRouter
pour que les modèles s'affichent
Problème: Console spam 400 errors quand clé API OpenRouter non configurée
- Frontend: Chat appelle getModels() sans vérifier si API key existe
- Backend: Retourne 400 au lieu de 200 avec tableau vide
Solutions:
- Frontend (Index.tsx:556): Ajout check settings.openrouter_api_key avant loadOpenRouterModels()
- Backend (openrouter.routes.js:28,93): Return 200 [] au lieu de 400 error quand pas de clé API
Résultat: Plus d'erreurs console, UI affiche simplement pas de modèles
PROBLÈME PERSISTANT: Le décalage d'1h persiste malgré les fixes.
ANALYSE COMPLÈTE:
Le types.setTypeParser doit être appliqué AVANT le Pool,
ET l'image Docker doit être rebuild (pas juste restart),
ET les anciens événements doivent être supprimés et resynchronisés.
AJOUTS:
1. scripts/full-diagnosis-timezone.js
- Diagnostic complet du problème
- Test du type parser (Date object vs string)
- Test insertion/lecture PostgreSQL
- Vérification événements réels
- Simulation API response
- Recommandations claires selon le résultat
2. FIX-TIMEZONE-FINAL.md
- Procédure COMPLÈTE étape par étape
- REBUILD obligatoire avec --no-cache
- Suppression événements corrompus
- Resynchronisation Google Calendar
- Vérifications multiples
- Dépannage si problème persiste
- Checklist finale
UTILISATION:
1. Diagnostic:
docker exec notes-todo-app node scripts/full-diagnosis-timezone.js
2. Si parser KO (renvoie Date objects):
docker-compose down
docker-compose build --no-cache notes-app
docker-compose up -d
3. Suppression anciens événements:
docker exec noteflow-postgres psql -U noteflow -d noteflow -p 5499 \
-c "DELETE FROM calendar_events"
4. Resynchroniser depuis interface web
5. Vérifier que heures = Google Calendar
Le diagnostic permettra d'identifier si:
- Le parser n'est pas actif → rebuild nécessaire
- Le parser fonctionne mais anciennes données → suppression nécessaire
- Autre problème → affichage exact du problème
Fichiers:
- scripts/full-diagnosis-timezone.js (nouveau)
- FIX-TIMEZONE-FINAL.md (guide complet)
SOLUTION FINALE du problème de décalage horaire:
PROBLÈME IDENTIFIÉ:
Avec SQLite: dates stockées comme strings, renvoyées comme strings ✅
Avec PostgreSQL: TIMESTAMPTZ automatiquement parsé en objets Date ❌
Le driver node-postgres (pg) convertit automatiquement les TIMESTAMPTZ
en objets JavaScript Date, ce qui causait des problèmes de timezone
différents de quand les dates étaient des strings avec SQLite.
SOLUTION APPLIQUÉE:
1. config/database.js lignes 6-12:
- Import de 'types' depuis pg
- types.setTypeParser(1184, ...)
- 1184 = OID de TIMESTAMPTZ
- Retourne la string ISO au lieu d'un objet Date
2. scripts/test-date-format.js (nouveau):
- Script de test pour vérifier format des dates
- Insère événement test à 10h Paris
- Vérifie comment PostgreSQL stocke et renvoie
- Compare avec comportement SQLite
- Diagnostic complet
COMPORTEMENT MAINTENANT:
PostgreSQL stocke: 2025-11-14 09:00:00+00 (UTC)
Driver pg renvoie: "2025-11-14T09:00:00Z" (string ISO)
Frontend parse: new Date("2025-11-14T09:00:00Z")
Frontend affiche: toLocaleTimeString(..., timeZone: 'Europe/Paris') = "10:00"
C'est le même comportement qu'avec SQLite! ✅
APRÈS REBUILD:
Les dates seront renvoyées comme strings ISO au lieu d'objets Date,
exactement comme avec SQLite, et l'affichage sera correct.
Plus besoin de:
- Migration timezone complexe
- Conversion timezone backend
- Le frontend gère tout avec timeZone: 'Europe/Paris'
Fichiers modifiés:
- config/database.js (types.setTypeParser)
- scripts/test-date-format.js (nouveau, diagnostic)
PROBLÈME PERSISTANT résolu avec 3 correctifs:
1. FRONTEND - Timezone explicite (src/pages/Index.tsx):
- Ligne 904-905: Ajout timeZone: 'Europe/Paris'
- Ligne 761: Ajout timeZone: 'Europe/Paris' pour alertes
Avant: toLocaleTimeString('fr-FR', { hour: '2-digit', minute: '2-digit' })
Après: toLocaleTimeString('fr-FR', { hour: '2-digit', minute: '2-digit', timeZone: 'Europe/Paris' })
Force l'affichage en heure de Paris même si navigateur dans autre timezone
2. BACKEND - Script correction forcée (scripts/force-fix-calendar-timezone.js):
- Diagnostic complet de l'état actuel
- Suppression FORCÉE de tous les événements
- Conversion TIMESTAMPTZ avec timezone Europe/Paris
- Vérification finale des types de colonnes
- Instructions étape par étape
Utilisation:
docker exec notes-todo-app node scripts/force-fix-calendar-timezone.js
3. DIAGNOSTIC approfondi:
- Affiche types colonnes PostgreSQL
- Montre exemples de dates stockées
- Compare format brut vs formaté
- Détecte problèmes timezone automatiquement
POURQUOI ÇA NE MARCHAIT PAS AVANT:
- Migration timezone peut ne pas avoir été appliquée
- Anciennes données encore présentes avec mauvais timezone
- Frontend n'avait pas timeZone explicite dans toLocaleTimeString
- Navigateur pouvait être dans autre timezone que Paris
SOLUTION MAINTENANT:
1. Script force la suppression + conversion
2. Frontend force timezone Europe/Paris
3. Nouvelles syncs Google Calendar auront bonnes heures
APRÈS REBUILD:
1. docker-compose build notes-app
2. docker-compose restart notes-app
3. docker exec notes-todo-app node scripts/force-fix-calendar-timezone.js
4. Resynchroniser Google Calendar dans interface web
5. Vérifier que heures correspondent
Fichiers modifiés:
- src/pages/Index.tsx (timeZone: 'Europe/Paris')
- scripts/force-fix-calendar-timezone.js (nouveau, correction forcée)
ANALYSE APPROFONDIE effectuée du problème de décalage horaire.
PROBLÈME IDENTIFIÉ:
La migration utilisait 'AT TIME ZONE UTC' au lieu de 'Europe/Paris'
ce qui causait une mauvaise interprétation des anciennes données.
CORRECTIONS APPLIQUÉES:
1. Migration timezone (scripts/migrate-calendar-timezone.js):
- Ligne 61: UTC → Europe/Paris pour start_time
- Ligne 69: UTC → Europe/Paris pour end_time
- Les anciennes données en heure locale sont correctement converties
2. API calendar events (routes/calendar.routes.js):
- Ajout de all_day dans le SELECT (ligne 348)
- Permettra détection correcte événements toute la journée
3. Script de diagnostic (scripts/diagnose-calendar-timezone.js):
- Vérifie timezone PostgreSQL
- Affiche format des dates stockées
- Compare UTC vs Europe/Paris
- Détecte si TIMESTAMPTZ appliqué
- Identifie événements avec mauvais timezone
- Recommandations de correction
UTILISATION DIAGNOSTIC:
docker exec notes-todo-app node scripts/diagnose-calendar-timezone.js
Le script affichera:
- Timezone serveur PostgreSQL
- Format des colonnes (TIMESTAMPTZ vs TIMESTAMP)
- Exemples de dates (brut, UTC, Paris)
- Format renvoyé par driver Node.js
- Recommandations si problème détecté
SOLUTION FINALE:
Après rebuild Docker:
1. La migration supprimera les anciens événements
2. Convertira avec bon timezone (Europe/Paris)
3. Resync Google Calendar récupérera bonnes dates
4. Les heures seront enfin correctes!
Fichiers modifiés:
- scripts/migrate-calendar-timezone.js (Europe/Paris)
- routes/calendar.routes.js (all_day ajouté)
- scripts/diagnose-calendar-timezone.js (nouveau)
Nettoyage de la page de connexion:
Suppressions:
- ❌ "Made by dyad" (composant MadeWithDyad)
- ❌ "Par défaut: admin / admin" (CardFooter)
La page de login est maintenant épurée et professionnelle.
Fichier modifié:
- src/pages/Login.tsx
- Ligne 4: CardFooter retiré des imports
- Ligne 5: MadeWithDyad supprimé
- Lignes 92-96: CardFooter supprimé
- Lignes 99-101: MadeWithDyad supprimé
Page de login minimaliste sans informations de connexion exposées.
LogiFlow
Claude