Claude
a1a95fa290
Symptôme : « tapis anti » renvoyait 40 articles sans rapport (mugs, miroirs, couvertures) avec des codes centraux contigus — c'est-à-dire le début du catalogue Qlik, pas un résultat de recherche. Cause : SearchResults + SelectValues. On ré-injectait les qText renvoyés par la recherche globale dans un SelectValues sur le champ, sans vérifier le retour et sans laisser à l'Engine le temps d'évaluer la sélection. Quand la sélection n'est pas appliquée, le cube renvoie simplement les premières lignes de la dimension « Article Code » — soit exactement les 40 lignes demandées. Correctifs : - Sélection via list object : SearchListObjectFor + AcceptListObjectSearch, c'est-à-dire le mécanisme d'un volet de filtre Qlik. Qlik applique sa propre sémantique de recherche et sélectionne lui-même les valeurs, sans réinjection de valeurs texte. Libellé d'abord, code centrale en repli. - Délai d'évaluation (QLIK_SETTLE_MS, défaut 250 ms) après ClearAll, après la recherche et après l'acceptation, comme le fait déjà l'extraction. - Garde-fou côté client : chaque ligne du cube est revérifiée contre le terme (tous les mots présents dans le libellé, insensible casse/accents, ou code correspondant). Une liste sans rapport avec la recherche est pire que zéro résultat. - Dédoublonnage par code centrale : un article référencé chez plusieurs fournisseurs produisait autant de lignes (vu sur « Couverture de Pique-nique », code 10636135, listé deux fois). - Diagnostic : inventaire des champs, nombre de valeurs trouvées, sélections actives et compteur de lignes écartées sont tracés dans les logs ; si tout est écarté, l'UI dit que le filtre n'a pas été appliqué au lieu d'afficher un « aucun résultat » trompeur. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
CollectFlow
CollectFlow est une application de révision d'assortiment et d'analyse de performances des produits en point de vente, conçue pour consolider les données issues de plusieurs fournisseurs et magasins.
Prérequis
- Node.js 18+ (pour le développement local)
- Docker et Docker Compose (pour le déploiement conteneurisé)
- PostgreSQL 16+
Lancer avec Docker
Le projet est configuré pour tourner dans un conteneur Docker optimisé (mode standalone de Next.js). Note : Vous devez disposer d'une base de données PostgreSQL séparée (le conteneur ne lance que l'application web).
1. Démarrer l'application
À la racine du projet, lancez :
npm run docker:build
# ou directement
docker-compose up -d --build
L'application sera accessible sur http://localhost:5643.
L'application sera attachée au réseau Docker externe nginx_default afin d'être exposée derrière votre reverse proxy Nginx. Assurez-vous que ce réseau existe (docker network create nginx_default).
2. Arrêter l'application
npm run docker:down
# ou directement
docker-compose down
Développement Local (Sans Docker)
Si vous préférez développer en local, vous devrez configurer votre propre base de données PostgreSQL.
- Installer les dépendances :
npm install
-
Configurer la connexion DB : Allez sur la page des Paramètres (
/settings) dans l'application pour configurer l'accès à votre PostgreSQL local. -
Lancer le serveur de développement :
npm run dev
Structure du Projet (BMAD)
Ce projet respecte l'architecture BMAD (Business, Model, Application/API, Data) :
src/features/*: Logique métier (Business) isolée par feature (ex:grid,snapshots)src/types/*: Interfaces TypeScript (Model)src/app/*: Routeurs Next.js UI et endpoints d'API (Application/API)src/db/*: Schémas Drizzle ORM et connexions (Data)