Le champ `users` est désormais sur le blueprint projet. Les blueprints
pochet/client perdent leur champ `projects`. La logique PHP (user-projects,
managers, controller, template, mark-all-read) lit project.users au lieu
de user.projects. Script de migration inclus.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Ajout toggle Kirby natif au-dessus du graphique
- Moyenne : courbe agrégée unique pour toutes les pages
- Pages les + visitées : multi-courbes pour le top 10
- Toggle masqué quand un filtre par page est actif
- PHP : visitsByDayByPage inclut toutes les pages
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Ajout filtre multiselect par page(s) dans le dashboard analytics
- Chart multi-courbes par page quand aucun filtre page sélectionné
- Options de pages indépendantes du filtre page (persistent à la sélection)
- Options de pages dépendantes du filtre utilisateur
- Tracking modal-file avec format "Projet / Label" dans dialog.js
- Tri alphabétique des options du filtre par page
- Fix user list 500 error (email string, client field check)
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Multiselect Kirby pour filtrer par utilisateur(s)
- Données de test alignées sur les vrais comptes
- Suppression bloc utilisateurs les plus actifs
- Route get-data supporte le filtre emails
- Améliorations UI filtres (layout dates + users)
- Autres modifs : menu, router, dialog, deploy workflow
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
Refactoring complet du plugin analytics : remplacement de la section
avec template Vue inline par un custom field compilé avec kirbyup.
Dashboard avec KPIs, line chart Chart.js et filtres par date.
Co-Authored-By: Claude Opus 4.6 <noreply@anthropic.com>
- Installation vue-i18n v11 et création des fichiers de traduction (fr.json, en.json)
- Création store locale avec détection hiérarchique (URL > localStorage > navigator)
- Modification des routes avec préfixe /:locale? optionnel
- Toggle FR/EN dans Menu.vue avec synchronisation immédiate
- Traduction de ~200 textes dans 27 composants Vue
- Suppression des labels hardcodés en français côté backend
- Ajout route Kirby catch-all en/(:all?) pour /en/ URLs
- Helper addLocalePrefix() pour préserver locale dans liens dialogs
- Traduction pseudo-élément CSS via data attribute
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Route toggle-hidden-project : utilisation collection Pages avec add/remove
puis toArray() + encode YAML (pattern de toggle-favorite)
- Controller site.php : ->values() au lieu de ->data pour retourner
un vrai tableau au lieu d'un objet
Co-Authored-By: Claude Sonnet 4.5 <noreply@anthropic.com>
- Blueprint : ajout champs moodboard et description
- Kanban : utilise ClientBrief au lieu de SimpleDocument
- Validation : support extended-brief depuis PDF et page images
- Navigation : paths dynamiques basés sur step.slug
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 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>
