Renamed from CLAUDE_PROJECT_OVERVIEW.md to follow standard naming convention
for automatic recognition. Added section documenting code standards and
work preferences.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
Virtual sample variations now display correctly when loading from URL hash.
Old URLs with underscores are normalized to hyphens on load. URL hash
updates automatically when navigating between variations.
Refactored both DynamicView and Selector components with explicit function
names, removed unnecessary comments, and improved code organization.
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
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>
