Problème : L'URL avec hash (#serumwc_lasertone_empty) n'ouvrait pas la bonne
piste/variation mais toujours la première.
Cause : Incohérence entre les underscores du hash et les tirets du slug backend.
slugify convertit les underscores en tirets, mais les slugs Kirby peuvent
varier.
Solution : Comparer le hash de 3 façons :
1. Comparaison directe
2. Hash avec underscores → tirets
3. Slug avec tirets → underscores
Cela gère tous les cas de figure.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
La div en dessous ne s'affichait pas dans le panel Kirby.
La progression s'affiche maintenant directement dans le bouton :
"En cours 0%" → "En cours 20%" → "En cours 100%" → "Terminé"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Ajout d'une ligne de texte sous le bouton pour afficher la progression :
- "Traitement : 10/50 projets (20%)" pendant le traitement
- "50 projets mis à jour avec succès" à la fin
- Tooltip aussi mis à jour avec la progression
Le bouton affiche "En cours…" et la progression détaillée est en dessous.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Problème : Le refresh cache de tous les projets timeout côté serveur à cause
du trop grand nombre de projets à traiter en une seule requête.
Solution : Batch processing avec indicateur de progression
- Backend : traite 10 projets par batch avec offset/limit
- Frontend : fait plusieurs requêtes successives et affiche la progression
- Timeout réduit à 60s par batch au lieu de illimité
- Bouton désactivé pendant le traitement
- Ajout invalidateNotificationsCache() pour vider aussi ce cache
Affichage : "15/50 (30%)" pendant le traitement, puis "Terminé (50)"
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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>
