simone/clienthub
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity
Files
f98828f75e0708edb0bf51a52d099810c164f275
clienthub/.planning/phases/11-catalog-database-view-ux-legacy-consolidation/11-DISCUSSION-LOG.md
T
simone 03898f2a59 docs(planning): v2.1 milestone setup + Phase 11 context/patterns 
- Archive v2.0 phases (07-10) under .planning/milestones/
- v2.1 REQUIREMENTS/ROADMAP (Phases 11-17: Offer Studio + Proposal AI)
- DESIGN-SYSTEM.md (database-view UI contract for Phases 11-14)
- Phase 11 CONTEXT, DISCUSSION-LOG, PATTERNS

Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
2026-06-13 15:07:06 +02:00

165 lines
8.7 KiB
Markdown
Raw Blame History

# Phase 11: Catalog Database-View UX & Legacy Consolidation - Discussion Log
> **Audit trail only.** Do not use as input to planning, research, or execution agents.
> Decisions are captured in CONTEXT.md — this log preserves the alternatives considered.
**Date:** 2026-06-13
**Phase:** 11-catalog-database-view-ux-legacy-consolidation
**Areas discussed:** Consolidamento offer_services — portata, Architettura sistema tag, Destino del campo 'category', Tabella database-view — colonne e comportamenti
---
## Consolidamento offer_services — portata
Investigazione preliminare: `offer_services`/`offer_micro_services` non sono solo "legacy morti" — alimentano attivamente `/admin/offers` e la sezione `OffersSection` lato cliente (prezzo cumulativo). Questo ha cambiato la portata della domanda rispetto all'assunzione iniziale ("consolidamento semplice").
### Portata del consolidamento
| Option | Description | Selected |
|--------|-------------|----------|
| Solo copia dati (audit trail) | Migrazione additiva: copia righe in `services` con `migrated_from`/`migrated_id` (pattern Phase 7), zero behavior change a `/admin/offers` e `OffersSection` | ✓ |
| Rewiring completo | `/admin/offers` e `OffersSection` leggono/scrivono direttamente da `services` in questa fase | |
**User's choice:** Solo copia dati (audit trail)
**Notes:** Coerente con Data Safety LOCKED + "compartimenti stagni" + lezione Phase 10 (crash da disallineamento sorgenti dati). Il rewiring completo è deferito a Phase 12.
### Tag automatico, status quo /admin/offers, verifica migrazione (batch di 3 domande)
| Option | Description | Selected |
|--------|-------------|----------|
| Sì, tag automatico | Le righe migrate da `offer_services` ricevono il tag "Offerta" per distinguerle nel catalogo unificato | ✓ |
| No tag | Nessuna marcatura delle righe migrate da `offer_services` | |
| Option | Description | Selected |
|--------|-------------|----------|
| Status quo (legacy) | `/admin/offers` continua a scrivere in `offer_services`/`offer_micro_services` come oggi | ✓ |
| Rewire subito | `/admin/offers` viene aggiornato in questa fase per usare `services` | |
| Option | Description | Selected |
|--------|-------------|----------|
| Solo verifica one-shot | Conteggio righe via script/log durante la migrazione (come Phase 7), nessun indicatore permanente | ✓ |
| Badge UI permanente | Indicatore visibile in `/admin/catalog` che mostra lo stato della migrazione | |
**User's choice:** Tag automatico "Offerta" + status quo su `/admin/offers` + verifica one-shot
**Notes:** Il tag "Offerta" sarà un tag normale del pool (vedi area successiva), non un marcatore di sistema.
---
## Architettura sistema tag
Investigazione preliminare: OFFER-08 (Phase 11, tag catalogo) e CRM-09 (Phase 14, tag lead) richiedono entrambi "tag multi-select con creazione al volo". La tabella `comments` (`entity_type`/`entity_id` polimorfico) è un precedente diretto per una junction riusabile.
### Tabella tags condivisa ora vs solo catalogo
| Option | Description | Selected |
|--------|-------------|----------|
| Condiviso ora (tags + junction polimorfica) | Nuova tabella `tags` + junction `entity_type`/`entity_id` (pattern `comments`), riusabile da Phase 14 senza rifare lo schema | ✓ |
| Solo catalogo | Tabella `service_tags` dedicata, da generalizzare eventualmente in Phase 14 | |
**User's choice:** Condiviso ora (tags + junction polimorfica)
**Notes:** Build-once-reuse-later — schema pronto ora, UI lead arriva in Phase 14.
### Namespace tag, colore badge, protezione tag "Offerta" (batch di 3 domande)
| Option | Description | Selected |
|--------|-------------|----------|
| Scoped per entity_type | I tag del catalogo (`services`) e i tag dei lead (futuro) sono pool separati, anche su tabella `tags` condivisa | ✓ |
| Pool globale unico | Tutti i tag condivisi tra tutte le entity_type, nessuna separazione | |
| Option | Description | Selected |
|--------|-------------|----------|
| Derivato dal nome (no DB) | Colore badge calcolato via hash nome→palette fissa (6-8 colori pastello da DESIGN-SYSTEM.md), nessuna colonna `color` | ✓ |
| Colonna color in tags | Colore scelto/salvato esplicitamente per ogni tag | |
| Option | Description | Selected |
|--------|-------------|----------|
| Tag normale | Il tag "Offerta" (auto-applicato alle righe migrate) è un tag normale del pool, rinominabile/eliminabile come ogni altro | ✓ |
| Tag protetto/system | Il tag "Offerta" non può essere rinominato/eliminato dall'utente | |
**User's choice:** Scoped per entity_type + colore derivato dal nome + tag "Offerta" normale
**Notes:** Nessuna colonna extra su `tags` oltre a nome/entity_type — palette e hashing sono dettagli di implementazione (Claude's Discretion).
---
## Destino del campo 'category'
### Relazione tra category e tags
| Option | Description | Selected |
|--------|-------------|----------|
| Campo separato | `services.category` resta testo libero indipendente, accanto ai tag multi-select — due dimensioni di classificazione | ✓ |
| Migrato/fuso nei tag | `category` viene convertito in tag e la colonna rimossa | |
**User's choice:** Campo separato
**Notes:** Categoria primaria + tag flessibili sono concetti distinti, entrambi utili nella tabella.
### Servizi senza category
| Option | Description | Selected |
|--------|-------------|----------|
| Nessun tag di default | Servizi senza `category` restano senza tag corrispondente | ✓ |
| Tag automatico "Senza categoria"/"Generale" | Creato e applicato automaticamente ai servizi senza categoria | |
**User's choice:** Nessun tag di default
**Notes:** Evita di popolare il pool tag con un tag "rumore" che non aggiunge informazione.
---
## Tabella database-view — colonne e comportamenti
### Colonna "Descrizione"
| Option | Description | Selected |
|--------|-------------|----------|
| Colonna piena, click-to-edit inline | Testo troncato con ellipsis, click espande in textarea inline, stesso pattern `EditableCell` delle altre colonne | ✓ |
| Spostata fuori riga | Descrizione visibile solo in un dettaglio/modal separato | |
**User's choice:** Colonna piena, click-to-edit inline
**Notes:** Coerente con lo stile Notion/Airtable — nessuna riga secondaria o modal.
### Quick-add row (OFFER-09)
| Option | Description | Selected |
|--------|-------------|----------|
| Nome + invio → riga editabile con prezzo €0,00 | Scrivere solo il nome e premere invio crea il servizio con `unit_price = 0`; la riga diventa subito normale ed editabile, prezzo corretto inline dopo | ✓ |
| Form esteso prima del salvataggio | La quick-add row richiede tutti i campi minimi prima di creare la riga | |
**User's choice:** Nome + invio → riga editabile con prezzo €0,00
**Notes:** Minimizza l'attrito di inserimento, coerente con "no modali".
### Servizi disattivati (active=false)
| Option | Description | Selected |
|--------|-------------|----------|
| Visibili attenuati, in fondo sotto divisore | Restano nella tabella con opacità ridotta (comportamento attuale), ma ordinati sotto una riga divisoria che li separa dai servizi attivi | ✓ |
| Nascosti di default con filtro toggle | Non mostrati a meno che l'utente non attivi un filtro "mostra inattivi" | |
**User's choice:** Visibili attenuati, in fondo sotto divisore
**Notes:** Mantiene visibilità storica senza nascondere dati, separazione visiva chiara.
### Colonna "azioni"
| Option | Description | Selected |
|--------|-------------|----------|
| Nessuna colonna azioni — stato come cella inline | Attivo/disattivo diventa toggle/checkbox cliccabile inline; tutte le modifiche via click-to-edit, zero bottoni per riga | ✓ |
| Colonna azioni con bottoni | Bottoni espliciti (edit/toggle/elimina) per riga | |
**User's choice:** Nessuna colonna azioni — stato come cella inline
**Notes:** Stile Notion/Airtable puro, coerente con DESIGN-SYSTEM.md (nessuna "azione riga-per-riga" salvo bulk in Phase 12+).
---
## Claude's Discretion
- Implementazione esatta dei componenti `EditableCell` e `TagMultiSelect` (DESIGN-SYSTEM.md ne definisce il comportamento, non il codice)
- Mapping esatto dei campi nella migrazione `offer_services` → `services` (`price`→`unit_price`, `transformation_description`→`description`)
- Verifica/eventuale fix del JOIN `quote_items` ↔ `service_catalog` in `admin-queries.ts` — flag per il researcher, non bloccante
- Palette colori esatta (6-8 pastello) e algoritmo hash nome→colore per i badge tag
- Posizionamento/stile esatto del divisore "inattivi"
## Deferred Ideas
- Rewiring completo di `/admin/offers` + `OffersSection` per leggere da `services` → Phase 12
- Riuso della tabella `tags`/junction polimorfica per i lead (CRM-09) → Phase 14
- Fix del JOIN `quote_items` ↔ `service_catalog` se risulta rotto → bugfix separato, non Phase 11
Reference in New Issue View Git Blame Copy Permalink