Claude 466cb53da2 fix(qlik-search): OU implicite entre les mots, cube abandonné, mauvais champs
Les logs de production ont tranché les trois causes.

1. La recherche de list object Qlik applique un OU entre les mots : « tapis
   anti » ramenait 17 696 libellés sur 1 070 645 — presque tous ne contenant
   que « anti ». On cherche désormais mot par mot pour retenir le plus sélectif,
   on filtre en ET côté client (tous les mots présents, insensible
   casse/accents), et on ne sélectionne que les valeurs retenues.

2. Sélectionner ces 17 694 valeurs faisait abandonner le cube suivant
   (code 15 « Request aborted »), d'où le repli systématique sur le catalogue
   local. La sélection est maintenant plafonnée à 1 000 valeurs, faite par
   numéro d'élément (SelectListObjectValues) plutôt que par texte, et les
   appels Engine retentent trois fois sur code 15.

3. Les champs détectés étaient les mauvais : article_libelle_ticket (libellé
   ticket tronqué) au lieu d'Article, et code_fournisseur (le code, d'où les
   « F005 » affichés) au lieu de Fournisseur. Une liste de préférences précède
   désormais l'heuristique, avec repli automatique sur le candidat suivant si
   un champ ne ramène rien.

Aussi :
- Un repli catalogue n'est plus mis en cache 10 min : une panne Qlik passagère
  se corrigeait uniquement avec « Relancer ».
- Le code 15 est traduit en message actionnable, et un terme trop large pour le
  moteur est signalé au lieu d'un « aucun résultat » trompeur.
- Les logs de la page ne relaient plus le bruit du client Qlik (thèmes,
  extensions).

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
2026-07-29 13:41:53 +00:00

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.

  1. Installer les dépendances :
npm install
  1. Configurer la connexion DB : Allez sur la page des Paramètres (/settings) dans l'application pour configurer l'accès à votre PostgreSQL local.

  2. 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)
S
Description
No description provided
Readme
4.6 MiB
0 Stars 1 Watchers 0 Forks
Languages
TypeScript 93.9%
JavaScript 3.6%
HTML 1.4%
CSS 1%
Dockerfile 0.1%