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)
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
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)
Correction du décalage de timezone de 1h dans Google Calendar
PROBLÈME:
- Les événements s'affichaient avec 1h de décalage
- Événement à 10h → affiché à 11h (ou 09h selon cas)
CAUSE:
- TIMESTAMP (sans timezone) dans PostgreSQL
- Google envoie dates avec timezone info
- PostgreSQL stockait sans timezone
- JavaScript réinterprétait avec timezone local
- = Double application du décalage
SOLUTION:
1. calendar_events: TIMESTAMP → TIMESTAMPTZ
- start_time: TIMESTAMPTZ (conserve timezone)
- end_time: TIMESTAMPTZ (conserve timezone)
2. Migration automatique:
- scripts/migrate-calendar-timezone.js
- Exécuté automatiquement au démarrage Docker
- Convertit les données existantes
- USING start_time AT TIME ZONE 'UTC'
3. Correction booléens all_day:
- Ligne 433: isAllDay ? 1 : 0 → isAllDay
- Ligne 451: isAllDay ? 1 : 0 → isAllDay
FICHIERS MODIFIÉS:
- config/database.js: TIMESTAMPTZ pour calendar_events
- routes/calendar.routes.js: Booléens corrigés
- docker-entrypoint.sh: Migration auto timezone
- migrations/002_calendar_timestamptz.sql: SQL manuel
- scripts/migrate-calendar-timezone.js: Script migration
DÉPLOIEMENT:
Au prochain rebuild Docker:
1. La table sera recréée avec TIMESTAMPTZ
2. Les événements existants seront migrés
3. Les nouvelles synchros utiliseront le bon format
4. Plus de décalage horaire!
Resynchronisez Google Calendar après déploiement
pour appliquer le nouveau format.
🐘 NoteFlow utilise maintenant EXCLUSIVEMENT PostgreSQL
CHANGEMENTS MAJEURS:
==================
1. Base de données (config/database.js)
✅ Remplacé par PostgreSQL (backup SQLite créé)
✅ Toutes les routes et services mis à jour
✅ database-loader.js supprimé (plus nécessaire)
2. Migration automatique (docker-entrypoint.sh)
✅ Attend que PostgreSQL soit prêt
✅ Détecte si PostgreSQL est vide
✅ Migre automatiquement SQLite si présent
✅ Lance le serveur après migration
3. Package.json
✅ Description mise à jour (PostgreSQL)
✅ Keywords: postgresql au lieu de sqlite
✅ sqlite3 gardé uniquement pour migration
4. Documentation
✅ POSTGRESQL-ONLY.md: Guide complet PostgreSQL
✅ Commandes, dépannage, sécurité
✅ Instructions de migration
MIGRATION UTILISATEUR:
=====================
Au prochain démarrage Docker:
1. Le container détecte PostgreSQL vide
2. Cherche ./data/notes.db (si existe)
3. Migre AUTOMATIQUEMENT toutes les données
4. Démarre avec PostgreSQL
COMMANDES:
=========
docker-compose build
docker-compose up -d
→ Tout se fait automatiquement!
Les données SQLite sont conservées comme backup dans ./data/
mais l'application n'utilise plus que PostgreSQL.
FICHIERS MODIFIÉS:
=================
- config/database.js (PostgreSQL uniquement)
- docker-entrypoint.sh (migration automatique)
- server.js + 11 routes + 2 services
- package.json (description + keywords)
- Documentation complète: POSTGRESQL-ONLY.md
Cette migration garantit:
- Performance optimale
- Meilleure gestion de la concurrence
- Support production à grande échelle
- Pas de perte de données (migration auto)
CORRECTIF URGENT: L'application chargeait toujours SQLite même avec
PostgreSQL configuré, causant une perte apparente de toutes les données.
Ajout de database-loader.js qui détecte automatiquement:
- DB_TYPE=postgres → PostgreSQL
- DATABASE_URL=postgresql:// → PostgreSQL
- Sinon → SQLite
Tous les routes et services mis à jour pour utiliser database-loader
au lieu de charger directement database.js.
Les données ne sont PAS perdues, elles sont dans PostgreSQL.
L'application se reconnectera correctement après redémarrage.
Fichiers modifiés:
- config/database-loader.js (nouveau)
- server.js
- routes/*.js (11 fichiers)
- services/*.js (2 fichiers)
Ajout de deux nouvelles fonctionnalités pour les notes:
1. Affichage des tags dans les cartes repliées:
- Les tags sont maintenant visibles dans les cartes de notes sans avoir à les ouvrir
- Badge avec icône TagIcon et nom du tag
- Chargement automatique des tags depuis la base de données
2. Icône de priorité cliquable:
- Bouton "!" en haut à droite de chaque carte de note
- Rouge (!) quand la note est prioritaire (toujours visible)
- Gris clair (!) quand non prioritaire (visible au hover)
- Toggle au clic pour marquer/démarquer comme prioritaire
- Les notes prioritaires sont triées en premier
Backend:
- Route PATCH /api/notes/:id/priority pour toggle la priorité
- Modification GET /api/notes pour charger tags et priority
- Tri par priority DESC, updated_at DESC
- Migration automatique pour ajouter colonne priority
- Index pour performance des requêtes de tri
Frontend:
- Interface Note étendue avec tags et priority
- Méthode togglePriority dans NotesService
- Affichage conditionnel de l'icône (toujours visible si prioritaire)
- Empêche le clic sur l'icône d'ouvrir la note (stopPropagation)
Migration:
- Ajout automatique de la colonne priority (INTEGER DEFAULT 0)
- Création d'index idx_notes_priority pour performance
- Fichier de migration 002_add_priority.sql créé pour référence
Problème majeur résolu:
- L'éditeur de notes réinitialisait le contenu à chaque modification
- Causé par dangerouslySetInnerHTML qui forçait React à synchroniser
- Résultat: impossible d'éditer les notes correctement
Solution:
- Suppression de dangerouslySetInnerHTML du RichTextEditor
- Conservation du useEffect avec deps vides pour initialisation unique
- Utilisation du key prop pour forcer remount lors du changement de note
- Éditeur maintenant complètement "uncontrolled"
Migration complète Google Calendar vers OAuth 2.0:
- Remplacement de l'API Key simple par OAuth 2.0 (Client ID + Secret)
- Nouvelle table google_oauth_tokens pour stocker les tokens
- Routes OAuth:
* GET /api/calendar/auth-url - Génère l'URL d'authentification
* GET /api/calendar/oauth-callback - Callback OAuth avec échange de code
* GET /api/calendar/auth-status - Vérifier le statut de connexion
* POST /api/calendar/disconnect - Déconnecter Google
- Gestion automatique du rafraîchissement des tokens expirés
- Interface utilisateur mise à jour:
* Champs Client ID et Client Secret
* Indicateur de statut de connexion (connecté/non connecté)
* Bouton "Se connecter avec Google" ouvrant popup OAuth
* Bouton "Déconnecter"
* URI de redirection affichée pour configuration Google Cloud Console
- Synchronisation maintenant avec calendrier principal de l'utilisateur
- Accès complet aux données privées du calendrier
Architecture:
- CalendarService.ts: Nouvelles méthodes getAuthUrl(), getAuthStatus(), disconnect()
- Settings: Ajout de google_client_id et google_client_secret
- Popup OAuth avec communication window.postMessage
- Gestion d'erreur avec re-authentification automatique si token expiré
Ajouts majeurs:
- Système de tags complet pour les notes
* Table note_tags en base de données avec indexes
* API REST pour CRUD des tags (GET/POST/DELETE)
* UI avec onglet Tags dans l'éditeur de notes
* Badges cliquables avec icônes et suppression au survol
* Modal pour ajouter des tags
- Liste automatique des modèles OpenRouter
* Nouvelle route API /api/openrouter/models
* Cache des modèles avec rafraîchissement automatique (1h)
* Dropdown dans l'admin avec tous les modèles disponibles
* Bouton "Actualiser" pour forcer le refresh
* Affichage du nom et description de chaque modèle
* Fallback sur input manuel si pas de clé API
Améliorations UI:
- Ajout de dates de création et modification dans les notes
- Affichage des dates dans les cartes et l'éditeur
- Format français pour toutes les dates
- Onglets passés de 4 à 5 colonnes pour inclure Tags
- Animation de chargement sur le bouton refresh des modèles
Architecture:
- Nouveau service TagsService.ts pour la gestion des tags
- Nouveau service OpenRouterService.ts pour l'API OpenRouter
- Nouvelles routes openrouter.routes.js
- Support Select component pour les dropdowns
- Modals InputModal utilisés pour les tags
Images multiples :
- Ajout table note_images dans la base de données
- Routes POST/GET/DELETE /api/notes/:id/images
- Dossier uploads/images séparé pour les images
- Support de plusieurs images par note
Google Calendar :
- Ajout table calendar_events
- Routes /api/calendar pour sync et récupération des événements
- Box Rendez-vous dans l'interface avec affichage des événements à venir
- Configuration Google Calendar dans l'admin (API key et Calendar ID)
- Synchronisation manuelle avec Google Calendar API
- Installation package googleapis
Corrections :
- Fix RichTextEditor: ajout dir="ltr" pour empêcher l'écriture RTL
- Fix Image type conflict (lucide-react vs Note interface)
- Ajout original_name à l'interface Image pour compatibilité
Interface :
- Box Rendez-vous empilée avec Todos et RSS dans la colonne droite
- Nouvel onglet Google Calendar dans l'administration
- Bouton "Synchroniser" pour rafraîchir les événements
1. Titre 'À faire' au lieu de 'Quick Tasks'
- Changé public/index.html ligne 126
- Meilleure localisation française
2. Affichage source RSS au lieu du modèle IA
- Ajout colonne feed_title à rss_summaries (migration auto)
- Backend stocke feed_title lors de la génération
- GET /api/rss/summaries retourne feed_title
- Frontend affiche 📰 Source + 📅 Date au lieu du modèle
- Plus pertinent pour l'utilisateur
3. Tri automatique des todos : actives en premier
- renderTodos() trie : actives avant complétées
- Si même statut : tri par ID décroissant (récentes en premier)
- Sort: a.completed ? 1 : -1
4. Système de notifications internes
- Remplacé TOUS les alert() par showNotification()
- Types : success, error, warning, info
- Animations : slide-in/slide-out depuis la droite
- Auto-fermeture après 4 secondes
- Bouton de fermeture manuelle
- Position : top-right, z-index 300
- Icônes SVG selon le type
- Couleurs : vert (success), rouge (error), jaune (warning), bleu (info)
Frontend - Notifications:
- showNotification(message, type, duration)
- closeNotification(notification)
- Container fixe en haut à droite
- Empilage vertical des notifications
- Escape HTML automatique
CSS - Nouveaux styles:
- .notifications-container (fixed, top-right)
- .notification + variations par type
- Animations slideInRight / slideOutRight
- Border-left colorée selon le type
- Responsive et accessible
Impact utilisateur:
✓ Plus de popups système alert() invasives
✓ Notifications élégantes et non-bloquantes
✓ Feedback visuel clair avec icônes et couleurs
✓ Source RSS affichée au lieu du modèle IA
✓ Todos actives toujours en haut
✓ Interface 100% en français
Files:
- public/index.html: Titre + container notifications
- public/css/skeleton.css: Styles notifications
- public/js/complete-app.js: showNotification() + remplacement 40+ alert()
- config/database.js: Migration feed_title
- routes/rss.routes.js: Stockage et retour feed_title
Backend:
- Récupération des vrais modèles depuis l'API OpenRouter
- Table rss_summaries pour stocker les résumés générés
- Limitation à 5 articles RSS au lieu de 10
- Route GET /api/rss/summaries pour récupérer les résumés
- Sauvegarde automatique des résumés en base de données
Frontend:
- Affichage conditionnel: résumés si activé, sinon articles
- Fonction renderRssSummaries() avec conversion Markdown→HTML
- Formatage du résumé (titres, listes, gras, italique)
- CSS complet pour .rss-summary avec typography
- Bouton résumer: crée note ou recharge bloc selon config
Comportement:
- Si rss_summary_enabled=1: affiche les 5 derniers résumés
- Sinon: affiche les 5 derniers articles
- Résumés formatés avec Markdown dans le bloc RSS
## Base de données:
- Table settings (key-value pour paramètres globaux)
- Table rss_feeds (url, title, description, enabled, last_fetched_at)
- Table rss_articles (feed_id, title, link, description, pub_date, content)
- Index optimisés pour performance
## Routes Settings (/api/settings):
- GET /api/settings - Récupérer tous les paramètres
- GET /api/settings/:key - Récupérer un paramètre
- PUT /api/settings/:key - Mettre à jour un paramètre
- DELETE /api/settings/:key - Supprimer un paramètre
- Middleware requireAdmin sur toutes les routes
## Routes RSS (/api/rss):
- GET /api/rss/feeds - Liste des flux RSS (admin)
- POST /api/rss/feeds - Ajouter flux RSS avec parsing validation (admin)
- PUT /api/rss/feeds/:id - Activer/désactiver flux (admin)
- DELETE /api/rss/feeds/:id - Supprimer flux (admin)
- POST /api/rss/fetch - Récupérer articles de tous flux actifs (admin)
- GET /api/rss/articles - Récupérer 10 derniers articles (tous users)
- POST /api/rss/summarize - Générer résumé OpenRouter (admin)
- GET /api/rss/models - Liste modèles OpenRouter (admin)
## Intégration OpenRouter:
- Appel API avec clé, modèle et prompt configurables
- Résumé intelligent des 10 derniers articles
- Prompt par défaut optimisé pour résumés d'actualités
- Support GPT-4, Claude 3, Gemini, Llama 3, Mistral, etc.
- Gestion erreurs et timeout
## Parser RSS:
- rss-parser installé pour parsing flux
- Gestion articles avec contenu, description, date
- Détection doublons par URL
- Update automatique infos flux
## Frontend HTML:
- Modal admin avec système à onglets (Users/RSS/OpenRouter)
- Modal changement mot de passe sans prompt navigateur
- Box RSS dans page principale affichage 10 derniers articles
- Bouton résumé IA dans header box RSS
- Inputs pour gestion flux RSS
- Configuration OpenRouter (API key, modèle, prompt, activation)
- Sélecteur modèles avec recherche
Prochaine étape: CSS + JavaScript pour fonctionnalités
## Corrections UX:
- Fix coins arrondis en bas des notes étendues (overflow: hidden)
- Remplacement prompt() par input inline pour ajout de tâches
- Bouton "Ajouter" avec validation au clic ou touche Entrée
- Expérience utilisateur fluide sans popups intrusifs
## Système de fichiers complet:
### Backend:
- Création table note_files (id, note_id, filename, original_name, file_size, mime_type, created_at)
- POST /api/notes/:id/files - Upload fichier (multer, 10MB max)
- GET /api/notes/:id/files - Liste fichiers d'une note
- GET /api/notes/files/:fileId/download - Téléchargement sécurisé
- DELETE /api/notes/files/:fileId - Suppression fichier
- Stockage dans public/uploads/files/
- Auto-création dossier si nécessaire
### Frontend:
- Bouton "Ajouter un fichier" dans footer des notes
- Input hidden fileInput pour sélection
- Affichage liste fichiers avec icône, nom, taille
- Boutons télécharger/supprimer par fichier
- Fonction formatFileSize() pour affichage lisible
- Event delegation pour tous les boutons fichiers
- Confirmation avant suppression
### Intégration:
- GET /api/notes charge maintenant files[] et files_count
- renderInlineFiles() génère HTML des fichiers
- downloadFile() ouvre download dans nouvel onglet
- deleteFile() avec confirmation dialog
- Reload automatique après upload/delete
- Conservation état étendu après opérations
### CSS moderne:
- .note-file-item avec hover effect
- .note-file-icon, .note-file-info, .note-file-actions
- Buttons download/delete avec transitions
- Design cohérent avec reste de l'app
- Truncate nom fichier avec ellipsis
Tous types de fichiers acceptés (PDF, DOC, ZIP, etc.)
- Migration auto colonne archived (BOOLEAN DEFAULT 0)
- Route GET /api/notes?archived=true/false pour filtrer
- Route PUT /api/notes/:id/archive pour archiver/désarchiver
- Chargement des todos avec chaque note (todos[], todos_count, todos_completed)
- Support filtrage par statut archivé
- Logs archivage/désarchivage
- Ajout d'une vérification automatique au démarrage
- Utilise PRAGMA table_info pour vérifier les colonnes existantes
- Ajoute image_filename si elle n'existe pas
- Résout l'erreur SQLITE_ERROR: no such column: n.image_filename
Claude
Michael