Problème : collectLight() ne retournait que id/type/isRead/date, causant
notification.author undefined dans le frontend.
Solution : Inclure tous les champs nécessaires à l'affichage (author, text,
location) mais toujours alléger en excluant les gros détails inutiles.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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>
Problème : Dans le kanban, la carte du brief client custom (Images) affichait
aussi le nombre de commentaires du PDF, alors qu'il n'y a pas de système de
commentaires pour les images du brief custom.
Solution : Filtrer pour ne compter que les commentaires des fichiers de type
'image', et non tous les fichiers du step.
Bonus : Suppression du paramètre obsolète ?step=images dans ClientBrief.vue
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Ces composants faisaient partie de l'ancien système de steps du Brief
qui a été supprimé. Ils ne sont plus utilisés.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Suppression du système de steps obsolète (Intro → ModeSelection → Images).
/client-brief affiche maintenant toujours le composant Images, sans conditions
ni paramètres d'URL (?step=images).
Les briefs avec PDF sont gérés via les dialogues uniquement.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problème 1 : Les notifications de brief validé depuis un PDF renvoyaient vers
/projects/xxx/client-brief au lieu de l'URL complète avec dialog et fileIndex.
Problème 2 : Les URL /projects/xxx/client-brief pour des briefs non créés
affichaient une page vide au lieu de rediriger vers le kanban.
Solutions :
- Stocker validationDialogUri lors de la validation du brief
- Utiliser ce dialogUri dans ContentProvider et Notifications.vue
- Rediriger vers le projet parent si brief vide et non validé
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>
