Roadmap OSM 3.0

[Dasc3er]

Questa issue descrive le scelte effettuate per la versione futura del gestionale OpenSTAManager (3.0), finalizzata a migliorare la struttura del gestionale secondo standard più recenti.

Framework

Il progetto è stato diviso in due parti, come segue:
👨🏻‍💻 Backend: Scritto in PHP, che utilizza il framework Laravel 8 (da Febbraio 2022 v9 e da Aprile 2023 v10). Si occupa della gestione delle routes, dei models, dei controllers, dei middlewares e di tutto ciò che riguarda il lato server del gestionale.

🖼️ Frontend: Scritto in Typescript (Javascript tipizzato) che utilizza il framework JS Mithril e il framework grafico Material Web/MWC (Material Design).

• Mithril gestisce tutte le views/pagine (aiutato da Inertia, approfondito sotto questo paragrafo).
• Material Web e MWC sono entrambi framework CSS/JS open source, sviluppati da Google, con cui costruire la nuova UI (sostituendo Bootstrap). Material Web è la versione di MWC con lo stile e i componenti del Material Design 3, non ancora completa di tutti i componenti, ma le mancanze di MDC verranno compensate da MWC (la versione 2), finchè non saranno disponibili i componenti aggiornati. Datatables è stato sostituito con il componente DataTable del Material Design, implementando anche filtri e paginazione.

Ponte fra backend e frontend: InertiaJS. Permette di condividere dati tra Laravel e Mithril, e gestire meglio il routing tra i due framework.

Sviluppo

Lo sviluppo della nuova versione avviene in una nuova branch 3.x: https://github.com/devcode-it/openstamanager/tree/3.x che includerà esclusivamente il core (nucleo) del gestionale.
Sia il core che tutti i moduli standard inclusi in OSM 2.x verranno ricreati da zero e il loro sviluppo avverrà in repo separati (Esempio: https://github.com/devcode-it/osm_module_attivita_tipi). Questo per favorire una modularità più ampia possibile. Sarà infatti possibile scegliere di installare il solo core, installare il core + tutti i moduli standard o il core con i moduli scelti. In sostanza, si avrà massima libertà nella scelta dei moduli da includere nella propria installazione di OSM.

Lo sviluppo di un modulo dovrà seguire le istruzioni dei pacchetti Laravel (descritte qui e qui). È già stato creato un repository "template", che permette di creare un nuovo modulo di esempio al volo. Verranno indicate ulteriori istruzioni successivamente nella documentazione ufficiale.

Modifiche di accesso

Per l'introduzione di Laravel, deve essere reso disponibile il solo accesso alla cartella public/.

Operazioni da definire e completare

• Rimozione dei plugin in favore di una gestione unificata come moduli
• Revisione dei vari componenti come pacchetti Laravel (Revisione dei Componenti #793 per logica personalizzata)
• Revisione del sistema di permessi tramite Middleware (Revisione del sistema di permessi #792) [moduli, plugin, widget, stampe, email, cronjob, ...]
• Implementazione del templating nelle email
• Interfaccia di base per il sistema di importazione/esportazione dei contenuti in vari formati
• Sistema di upload personalizzabile ed estendibile a servizi esterni (Revisione del sistema degli allegati #791)
• Generalizzazione sistema evasioni documenti (Generalizzazione sistema evasioni documenti #786)con revisione degli stati
  • Stato del documento
  • Stato di riferimento (non importato, parzialmente importato, importato)
  • Come gestire la traslazione automatica tra stati sulla base del documento di riferimento?
• Separazione dei sezionali (strettamente legati ai documenti) dai segmenti (filtri selezionabili manualmente dall'utente) (Spostare la gestione dei “Segmenti” in nuovo panel all’interno del modulo “Viste”. #206)
• Introduzione di un gestore dei menu principali del gestionale scollegato dalla logica dei moduli
• Rimozione delle query a database per i moduli di default, in modo tale da avere fisicamente raggiungibile la query e mantenendo la personalizzabilità esclusivamente a database (da considerare per le Viste)
• Rimuovere il supporto a versioni MySQL troppo vecchie (Compatibilità MySQL #355)
• Miglioramento della gestione interna dei totali (prezzo, iva, ...) per le righe in generale e i documenti (Miglioramento struttura righe/articoli/sconti/descrizioni #546)
• Revisione del sistema di aggiornamento
  • Controlli di integrità e correttezza di file e database
  • Backup automatico
  • Anteprima dell'aggiornamento
  • Ripristino da backup indipendente in caso di errori
• Revisione dei campi idtipo* e idstato* in id_tipo_* (da cambiare in id_tipo) e id_stato
• Sistema di chat e controllo utenti connessi

---

La roadmap qui indicata non è definitiva e può essere soggetta a cambiamenti anche considerevoli.

[Dasc3er]

Ulteriori punti di interesse per la nuova versione:

• Gestione modulare attraverso Composer #45 propone l'utilizzo di Composer come sistema di gestione dei moduli, semplificato dall'introduzione di Laravel Modules
• Nuova tabella zz_user_setting #74 introduce una sezione di Impostazioni specifiche per l'utente, utili per ampliamenti futuri (notifiche browser, temi, lingua, ...)
• Maggiore precisione nei calcoli #99 propone l'utilizzo di una libreria per l'esecuzione dei conti numerici del gestionale, al fine di migliorare la stabilità e l'affidabilità dei risultati (attualmente gli importi sono gestiti tramite semplici float nativi, che causano problemi in casi estremi). In particolare, con le classi Eloquent si potrebbe implementare internamente brick/math per la gestione dei calcoli relativi.
• Strutturazione actions.php esterni per sviluppare più moduli esterni #212 discute la gestione della struttura al fine delle personalizzazioni di moduli e funzionalità di base (senza particolari risultati pratici)
• Salvataggio informazioni per documenti evasi #248 propone il salvataggio delle informazioni collegate ai documenti all'emissione (in particolare, indirizzi e sedi delle Anagrafiche) per evitare la falsificazione dei dati per modifiche successive. Similmente, Miglioramento movimentazione documenti in Bozza #787 discute della gestione dei movimenti degli Articoli, che dovrebbero essere effettuati solo all'emissione del documento. Ancora, Mantenimento prima nota e scadenze durante riapertura fatture #818 studia le problematiche attuali alla riapertura delle Fatture.
• Standardizzazione dei campi #311, Standardizzare la sede legale #310, Standardizzare la Ritenuta D'Acconto #309 prevedono alcune correzioni sulla struttura interna di Stati documenti, Sedi anagrafiche e la gestione della Ritenuta d'Acconto (quest'ultima da considerare in vista degli aggiornamenti più recenti di Fattura Elettronica)
• Nome allegati via mail #297 richiede di migliorare l'interfaccia di invio email per permettere la personalizzazione dei nomi degli allegati in modo dinamico
• Aggiornamento del database in sviluppo #346 propone di migliorare la gestione delle modifiche al database tramite l'utilizzo delle migrazioni, ovvero file fisici ristretti a un piccolo numero di query (solitamente 1 per modifica al database). Tramite Laravel, la procedura di integrazione con questo sistema è automatica (anche per i moduli) e la generazione si effettua dinamicamente tramite Artisan. In riferimento agli aggiornamenti, è di interesse Revisione sistema di aggiornamento #795 per il miglioramento della procedura pratica di aggiornamento tramite archivio ZIP.
• MIGLIORIA: Serial number deve essere univoco sullo stesso articolo #658, Miglioramento del sistema dei seriali  #851 discutono le problematiche relative al sistema attuale di gestione dei seriali (in particolare, il riutilizzo dei serial number non è permesso al momento). Movimentazione non tiene conto del Serial Number #933 richiede lo spostamento di seriali tra sedi.
• Miglioramento evasione contratti e preventivi #788 propone un nuovo sistema per l'evasione di Contratti e Preventivi
• Introduzione sistema di gestione per gli utenti connessi #797 propone un sistema di gestione degli utenti connessi, sia per maggiore sicurezza che per una eventuale chat interna
• Revisione del sistema di traduzione #800 considera le problematiche nella gestione delle traduzioni dei contenuti fissi a database (moduli e diciture automatiche in particolare)
• Codice metodo pagamento associato alla rate #830 propone la possibilità di associare pagamenti distinti alle diverse rate delle Fatture
• SCADENZARIO - Individuazione della rata  #356, Aggiunta numero rata in Scadenzario e Prima Nota #833 e MIGLIORIA: Problema con lo scadenzario #877 descrivono la necessità di gestire le rate dello Scadenzario in modo distinto (evitando il comportamento attuale che completa le rate in ordine)