Questo file documenta miglioramenti futuri, migrazioni pianificate, e note tecniche importanti per il progetto LibreFolio.
I TODO completati sono in TODO_Completati.md.
Data aggiunta: 22 Gennaio 2026
Status: ⏳ IN ATTESA (v9 in alpha)
Priorità: Bassa (fino a release stabile)
Abbiamo scelto di usare TanStack Table v8 con un adapter custom Svelte 5 invece dell'adapter ufficiale @tanstack/svelte-table per i seguenti motivi:
- v8 adapter ufficiale (
@tanstack/svelte-table): Non compatibile con Svelte 5 (usa API interne Svelte 3/4) - v9 con supporto Svelte 5: Ancora in versione alpha (
9.0.0-alpha.x)
- Libreria:
@tanstack/table-core@^8.21.3(stabile) - Adapter: Custom in
frontend/src/lib/tanstack-table/
Quando TanStack Table v9 sarà rilasciato come stabile con supporto ufficiale Svelte 5:
- Installare l'adapter ufficiale
@tanstack/svelte-table - Aggiornare import in tutti i componenti
- Rimuovere la cartella
src/lib/tanstack-table/(adapter custom) - Testare tutte le tabelle (Files, Assets, Transactions, FX)
Data aggiunta: 23 Gennaio 2026
Status: 📋 PIANIFICATO
Priorità: Bassa
Il riordinamento colonne nella DataTable funziona con drag & drop su desktop, ma su mobile usiamo bottoni su/giù. Potrebbe essere migliorato con touch drag nativo.
- Verificare comportamento su dispositivi touch reali (iOS Safari, Android Chrome)
- Se necessario, implementare touch drag con
touchstart,touchmove,touchend - Oppure integrare libreria come SortableJS con opzione
handle
Data aggiunta: 20 Febbraio 2026
Status: ⏳ IN ATTESA (richiede API backend)
Priorità: Media
Dipendenza: Endpoint /api/v1/users o /api/v1/admin/users
L'UploadedFile ha il campo uploaded_by_user_id ma non esiste un endpoint per risolvere gli ID utente in username/email. Serve per:
- Aggiungere colonna "Uploaded by" nella tabella files (come la colonna Broker in BRIM)
- Filtro dropdown per utente in modalità grid (accanto al search per nome)
- Badge colorati come nel BRIM (stessa funzione calcolo colori)
- Creare endpoint backend
GET /api/v1/admin/users(lista utenti, admin only) - Nel frontend, colonna utente visibile se
users.length > 1 - Filtro frontend-only con dropdown
- Riutilizzare pattern filtri di
FilesTable/urlFilters
Data aggiunta: Gennaio 2026
Status: 📋 PIANIFICATO → Architettura definita in plan-phase05-to-08-upgrade.md §10 (GDPR/Sharing)
Priorità: Media
La visibilità dei dati di altri utenti da parte del superuser deve essere ripensata per essere GDPR compliant.
- Superuser non vede dati personali di altri utenti senza consenso esplicito
- Log di accesso ai dati di altri utenti
- Anonimizzazione dei dati visualizzati (solo statistiche aggregate)
- Meccanismo di "data request" invece di accesso diretto (utente concede accesso all'assistenza per x tempo)
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Alta (Phase 6)
La pagina dell'asset dovrebbe mostrare il prezzo corrente in alto con la possibilità, cliccando su un punto del grafico, di aprire un'interfaccia piccola per modificare il valore di quel giorno. Sotto il grafico, per ogni transazione (slot per slot), mostrare il prezzo d'acquisto e la variazione rispetto ad oggi (guadagno/perdita), con uno storico del guadagno di quella transazione.
- Prezzo in alto, editabile cliccando sul punto nel grafico
- Sotto: lista slot transazioni con prezzo d'acquisto, variazione %, storico
- Grafico ECharts con click-to-edit
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO → Phase 6 §6.4 + Phase 7 §7.6 (vedi plan-phase05-to-08-upgrade.md)
Priorità: Alta (Phase 7)
All'import delle transazioni (BRIM), per ogni riga deve essere ricercato un asset corrispondente. Se non viene trovato, all'utente viene chiesto di selezionare tra:
- Asset già esistenti nel database
- Asset trovati con query di ricerca ai vari provider plugin (yfinance, JustETF, etc.)
Se l'utente seleziona un asset da un provider esterno, deve essere creato automaticamente l'asset associato nel database.
Import riga → Cerca asset matching
├─ Trovato → Link automatico
└─ Non trovato → Modale selezione:
├─ Asset esistenti
├─ Risultati ricerca provider
└─ Creazione manuale
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Alta (Phase 5)
La pagina dei tassi di cambio dovrebbe avere un grafico editabile come quello dell'asset:
- Click su un punto per modificare il valore di quel giorno
- Sotto il grafico, una tabella con le priorità dei provider (ECB, FED, BOE, SNB)
- Parametri configurabili per ciascun provider
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Media
Sia per i prezzi degli asset che per i tassi di cambio, il grafico deve avere un pulsante per richiedere l'aggiornamento automatico dei valori. Nella finestra di dialogo:
- Scegliere un frame temporale di richiesta
- Warning che l'operazione sovrascrive tutti i valori attuali nel range
- Progress bar durante l'aggiornamento
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Alta (architettura core)
Diverse giurisdizioni usano metodi diversi per determinare quale lotto vendere in caso di vendita parziale:
- Italia: Prezzo Medio di Carico (PMC)
- USA: FIFO, LIFO, Select ID (scelta specifica dell'utente)
- Altre: HIFO (Highest In First Out), etc.
- Impostazioni Broker: Nella zona short/long del broker, selettore per il metodo di vendita supportato (FIFO, LIFO, PMC, Select ID)
- Preferenze Utente: Impostazioni di default per metodo di vendita
- Impostazioni Admin: Default globale per nuovi utenti
- Collegamento Transazioni: Il sell deve essere collegato ai buy tramite
link_transactions_id:- FIFO/LIFO: collegamento algoritmico
- Select ID: scelto dall'utente
- PMC: nessun collegamento (calcolo on-the-fly)
- Analizzare le strade per lo split dei buy: slittare buy e connettere la parte residua, tabella di appoggio, lista di link
- Deve essere possibile identificare transazioni già importate per evitare doppio import
- Per PMC il problema del collegamento non sussiste, basta calcolare il valore on-the-fly
- I plugin BRIM in fase di vendita devono fornire un dizionario di remap con le transazioni linkate più probabili
- Il vincolo di over-sell va esteso nell'import
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Media
L'import delle transazioni deve permettere di fare split nel cash-in e cash-out per tracciare le varie fonti dei soldi. A database lo split non deve far perdere la transazione padre (per evitare doppio import).
- Tabella di supporto per legare le transazioni split
- UI: box unico dove le righe sono gli split
- In fase di creazione, i totali degli split devono rispettare quelli della transazione padre
- Anche in modifica questo vincolo deve essere mantenuto
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Alta (Phase 7)
Deve essere possibile parsare contemporaneamente più file, anche di diversi broker. L'interfaccia deve permettere di muoversi tra i vari fogli e impostare i collegamenti.
- Pulsante "Check" per validare le regole e ottenere in risposta elenco di errori e warning
- Superamento soglie di check
- Navigazione tra fogli/broker
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Media (Phase 8)
Nel diagramma dei guadagni dalle varie transazioni:
- Asse Y sinistra: scala dei valori/percentuali dell'asset
- Asse Y destra: scala di guadagno/perdita delle singole transazioni di buy
- Per ogni evento di buy, un nuovo grafico parte da 0 in y a quella data
- Una linea con area che rappresenta la sommatoria cumulativa dei guadagni
- Evento di vendita + tasse + commissione: doppia freccia verso il basso (da definire)
- Tabella con i buy in ogni riga
- Colonne: valore attualmente investito
- Sotto: barra con valore stimato + guadagnato
- Deve distinguere tra valore potenziale e realizzato (vendite parziali/totali)
- Selettore metodo di analisi (FIFO, LIFO, PMC, etc.)
Data aggiunta: 20 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Bassa (futuro)
Creare un assistente AI basato su MCP server chiamato "QuarkAI".
- Raccolta automatizzata notizie mercati azionari
- Notifiche su Telegram (o simili) quando rileva eventi che richiedono attenzione
- Recap giornaliero (es. alle 20:00) con sommario eventi rilevanti
## 📌 [Titolo]
**Data aggiunta**: [Data]
**Status**: [⏳ IN ATTESA | 📋 PIANIFICATO | 🔄 IN CORSO | ✅ COMPLETATO]
**Priorità**: [Alta | Media | Bassa]
### Contesto
[Descrizione del problema o motivazione]
### Azione Futura
[Passi da eseguire quando sarà il momento]
### Riferimenti
[Link a documentazione, issue, PR]
Data aggiunta: 23 Febbraio 2026
Status: 📋 PIANIFICATO
Priorità: Media
Quando si passa dalla modalità griglia (preview 120x120) alla modalità lista (preview 48x48) nella pagina files, il browser fa nuove richieste al backend per le stesse immagini a risoluzione inferiore. Questo succede perché le URL sono diverse (?img_preview=120x120 vs ?img_preview=48x48).
Sarebbe più efficiente riutilizzare la risorsa già caricata a risoluzione maggiore e lasciare al browser il ridimensionamento CSS, evitando chiamate network ridondanti.
- Creare un Map globale lato client (
imagePreviewCache: Map<fileId, {maxSize: number, objectUrl: string}>) - Nel componente
LazyImage, prima di fare fetch, controllare se il fileId è già in cache a risoluzione >= quella richiesta - Se sì, usare l'objectUrl già disponibile e fare
object-fit: coverCSS - Se no, fare la richiesta normale e salvare in cache
- Gestire la pulizia cache con
URL.revokeObjectURL()quando i componenti vengono distrutti - Eventuale Service Worker per intercettare le richieste
?img_preview=e servire versioni cached
- La cache backend (50MB, TTL 1h) già mitiga il problema server-side
- Questa ottimizzazione è puramente client-side per evitare roundtrip network
- Valutare l'impatto su memoria del browser se molte immagini sono in griglia