Problème : Les notifications étaient collectées à chaque requête sur
projects.json, causant des problèmes de performance et de mémoire.
Solution : Mise en cache des notifications par projet et par utilisateur
- Nouvelle méthode getNotificationsLight() dans ProjectPage avec cache
- Cache invalidé automatiquement via les hooks existants (page/file update)
- Cache par utilisateur pour inclure le isRead spécifique
Performance : Les notifications sont calculées une fois puis servies depuis
le cache jusqu'à ce qu'un changement survienne (commentaire, brief, etc.)
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problème : projects.json.php causait un dépassement mémoire en collectant
toutes les notifications complètes (avec author, location, text, etc.) pour
tous les projets.
Solution : Nouvelle méthode collectLight() qui ne retourne que les données
minimales nécessaires au frontend pour afficher les indicateurs :
- id, type, isRead, date
- location.project.uri (pour le filtrage)
Les détails complets sont toujours chargés dans project.json.php individuel.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problème : projects.json.php collectait les notifications dérivées pour TOUS
les projets d'un coup, ce qui causait un dépassement de mémoire (HTTP 500).
Solution :
- projects.json.php : Ne collecte plus les notifications (retourne [])
- project.json.php : Collecte les notifications uniquement pour le projet affiché
Les notifications seront chargées à la demande quand on ouvre un projet,
pas lors du listing initial.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Remplace le système de notifications stockées par un système de providers
qui dérivent les notifications des données existantes (commentaires, réponses,
demandes de projet, demandes de rendez-vous, validations de brief).
- Ajout du NotificationCollector et de l'interface NotificationProvider
- Création de 5 providers : Comment, Reply, ProjectRequest, AppointmentRequest, Content
- Métadonnées de notifications stockées directement sur les entités source
- Nouvelles routes mark-as-read et mark-all-read
- Mise à jour du frontend pour le nouveau système
- Route de migration pour les données existantes
Co-Authored-By: Claude Opus 4.5 <noreply@anthropic.com>
- project model : refactor getSteps() method
- create dialog store
- create DialogWrapper component that open the dialog corresponding to the URL query param
- l'étape courante est déterminée en fonction des données de la page
- les images sont ajoutées au champ
- les images déjà ajoutées sont affichées directement
- changement donnée briefClient -> clientBrief (cohérence avec le nommage front)
