Miglioramenti FE

This commit is contained in:
Thomas Zilio 2018-09-18 15:57:55 +02:00
parent 87ede5910e
commit 0c1d9c43d2
23 changed files with 3149 additions and 1454 deletions

View File

@ -1,93 +0,0 @@
template:
url: https://github.com/pnowy/CouscousNativeTemplate
include:
- docs
branch: gh-pages
baseUrl: https://devcode-it.github.io/openstamanager
github:
user: devcode-it
repo: openstamanager
title: OpenSTAManager
subTitle: Il software gestionale open-source per l'assistenza tecnica e la fatturazione
fontAwesomeIcon: fa fa-cog
footerText: 'Progettato e sviluppato da DevCode.'
googleAnalyticsCode: UA-42808312-1
scripts:
after:
- php sami.phar update .sami
# The left menu bar
menu:
sections:
main:
name: Introduzione
items:
home:
text: Home
relativeUrl: index.html
installazione:
text: Installazione
relativeUrl: installazione.html
aggiornamento:
text: Aggiornamento
relativeUrl: aggiornamento.html
contribuire:
text: Contribuire
relativeUrl: contributing.html
structure:
name: Strutture
items:
moduli:
text: Moduli
relativeUrl: structure/moduli.html
plugin:
text: Plugin
relativeUrl: structure/plugin.html
stampe:
text: Stampe
relativeUrl: structure/stampe.html
widget:
text: Widget
relativeUrl: structure/widget.html
more:
name: Approfondimenti
items:
nucleo:
text: Nucleo
relativeUrl: more/nucleo.html
upload:
text: Upload
relativeUrl: more/upload.html
extra:
text: Extra
relativeUrl: more/extra.html
api:
text: API
relativeUrl: more/api.html
base:
name: Personalizzazione
items:
framework:
text: Framework
relativeUrl: base/framework.html
assets:
text: Assets
relativeUrl: base/assets.html
links:
name: Link utili
items:
docs:
text: Documentazione
relativeUrl: docs/
osm:
text: Sito web
absoluteUrl: http://www.openstamanager.com
forum:
text: Forum
absoluteUrl: http://www.openstamanager.com/forum

View File

@ -1 +0,0 @@
Deny from all

View File

@ -1,89 +0,0 @@
---
currentMenu: aggiornamento
---
# Aggiornamento
**Attenzione**: Questa documentazione è esclusivamente relativa all'aggiornamento del software. Per maggiori informazioni sull'installazione consultare la documentazione relativa nella sezione [Installazione](Installazione.md).
Esistono due procedure ufficiale per effettuare l'aggiornamento di OpenSTAManager in modo corretto: una semplificata (_consigliata_) e una manuale.
In ogni caso, il corretto procedimento prevede di [scaricare una release ufficiale del progetto](https://github.com/devcode-it/openstamanager/releases) ed **effettuare un backup della versione corrente** (comprensivo di file e database).
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Aggiornamento semplificato](#aggiornamento-semplificato)
- [Aggiornamento manuale](#aggiornamento-manuale)
- [Migrazione dalla versione 1.x](#migrazione-dalla-versione-1x)
- [Recupero della password](#recupero-della-password)
- [Account comune](#account-comune)
- [Account amministrativo](#account-amministrativo)
<!-- /TOC -->
## Aggiornamento semplificato
La procedura di aggiornamento semplificato ha l'obiettivo di fornire un sistema di facile utilizzo per favorire l'aggiornamento, e migliorare in questo modo l'interazione con l'utente finale.
L'utilizzo di questa procedura è però sottoposto alla seguenti condizioni nelle impostazioni PHP:
- `upload_max_filesize` >= 16MB
- `post_max_size` >= 16MB
Di seguito la procedura:
1. Accedere con un account amministrativo
2. Entrare nel modulo **Aggiornamenti** (disponibile nel menu principale a sinistra, eventualmente sotto la dicitura **Strumenti**)
3. Selezionare il file _.zip_ della release attraverso l'apposita sezione "Carica un aggiornamento" e cliccare sul pulsante "Carica"
Dopo l'esecuzione di queste azioni, il gestionale effettuerà automaticamente il logout di tutti gli utenti connessi e renderà disponibile l'interfaccia di aggiornamento.
## Aggiornamento manuale
La procedura di aggiornamento manuale è resa disponibile per ovviare ai problemi relativi al caricamento del file _.zip_ (in alcuni casi il file non viene correttamente rilevato, non sono disponibili i permessi per caricare file oppure la dimensione del file eccede il limite di upload sul server).
Di seguito la procedura:
1. De-comprimere il contenuto del file _.zip_ in una cartella temporanea
2. Rinominare il file `VERSION` dell'installazione corrente in `VERSION.old` (rispettando minuscole e maiuscole) [facoltativo a partire dalla versione 2.3]
3. Copiare i file della nuova versione dalla cartella temporanea alla cartella del server, in modo che le cartelle principali (`files`, `modules`, `templates`, ...) vengano sovrascritte
Dopo l'esecuzione di queste azioni, il gestionale effettuerà automaticamente il logout di tutti gli utenti connessi e renderà disponibile l'interfaccia di aggiornamento.
## Migrazione dalla versione 1.x
E' possibile effettuare la migrazione da una qualsiasi versione 1.x alla nuova 2.0, seguendo una procedura un po diversa dalle precedenti:
1. Scaricare la versione 2.0 per la migrazione da SourceForge ([openstamanager-2.0-migrazione.zip](https://sourceforge.net/projects/openstamanager/files/openstamanager/openstamanager-2.x/))
2. Creare un backup completo della versione in uso
1. De-comprimere il contenuto del file _.zip_ in una cartella temporanea
4. Effettuare le seguenti operazioni dal backup della precedente versione alla cartella della versione 2.0:
- Copiare il file `VERSION`, rinominandolo in `VERSION.old`
- Copiare il file `config.inc.php`
- Copiare la cartella `files/`
- Copiare i contenuti della cartella `/modules/magazzino/articoli/images/` in `/files/articoli/`
- Copiare la cartella `templates/` (mantenendo però i file `pdfgen.php` e `pdfgen_variables.php` della versione 2.0)
Dopo l'esecuzione di queste azioni, il gestionale renderà disponibile l'interfaccia di aggiornamento.
**Attenzione**: le stampe di _Interventi_, _Riepilogo interventi_, _Contratti_ e _Preventivi_ potrebbero non essere compatibili per via dellaggiornamento degli orari di lavoro, perciò è possibile riscrivere solo la parte di calcolo ore o partire dal template nuovo e apportare le dovute modifiche.
## Recupero della password
Non esiste una procedura semplificata per permettere il recupero della password degli account di amministrazione (di default, _admin_) o di quelli comuni.
Si ricorda che è comunque possibile **cambiare** la password in ogni momento, se è stato effettuato l'accesso, attraverso l'utilizzo del modulo **Utenti e permessi** (**Gestione permessi** per versioni precedenti alla 2.3) disponibile sotto la dicitura **Strumenti**.
Può però essere necessario **reimpostare** la password, in particolare se è stata dimenticata, per ripristinare l'accesso ad OpenSTAManager.
### Account comune
Per procedere alla reimpostazione della password di un account comune (non amministrativo) è necessario accedere con un account amministrativo e utilizzare il modulo **Utenti e permessi** (**Gestione permessi** per versioni precedenti alla 2.3), disponibile sotto la dicitura **Strumenti**.
In particolare, una volta entrati nella corretta categoria di accesso (_Agenti_, _Amministratori_, _Clienti_, ...) dell'account da modificare, è possibile utilizzare la procedura semplificata di cambio password attraverso l'_icona del lucchetto aperto_.
Nel caso non sia possibile accedere con un account amministrativo, contattare l'amministratore.
### Account amministrativo
Per reimpostare la password di un account amministrativo è possibile procedere in due modi:
- Se esiste un altro account amministrativo, seguire la procedura precedente per gli account comuni;
- Accedere al database ed eseguire la seguente query:
```sql
UPDATE `zz_users` SET `password` = MD5('nuova_password') WHERE `username` = 'admin';
```

View File

@ -1,162 +0,0 @@
---
currentMenu: installazione
---
# Installazione
- [Requisiti](#requisiti)
- [Installazione](#installazione)
- [Versioni](#versioni)
- [GitHub](#github)
- [Strumenti utili](#strumenti-utili)
- [Windows](#windows)
- [Linux](#linux)
- [MAC](#mac)
- [Problemi comuni](#problemi-comuni)
- [Schermata bianca](#schermata-bianca)
- [Blocco dell'installazione (0%)](#blocco-dellinstallazione-0)
## Requisiti
L'installazione del gestionale richiede la presenza di un server web con abilitato il [DBMS MySQL](https://www.mysql.com) e il linguaggio di programmazione [PHP](http://php.net).
- PHP >= 5.6
- MySQL >= 5.6.5
Per ulteriori informazioni sui pacchetti che forniscono questi elementi di default, visitare la sezione [Installazione](https://devcode-it.github.io/openstamanager/installazione.html) della documentazione.
## Installazione
Per procedere all'installazione è necessario seguire i seguenti punti:
1. [Scaricare una release ufficiale del progetto](https://github.com/devcode-it/openstamanager/releases).
2. Creare una cartella (ad esempio `openstamanager`) nella root del server web installato ed estrarvi il contenuto della release scaricata. Il percorso della cartella root del server varia in base al software in utilizzo:
- LAMP (`/var/www/html`)
- XAMPP (`C:/xampp/htdocs` per Windows, `/opt/lampp/htdocs/` per Linux, `/Applications/XAMPP/htdocs/` per MAC)
- WAMP (`C:\wamp\www`)
- MAMP (`C:\MAMP\htdocs` per Windows, `/Applications/MAMP/htdocs` per MAC)
3. Creare un database vuoto (tramite [PHPMyAdmin](http://localhost/phpmyadmin/) o riga di comando).
4. Accedere a <http://localhost/openstamanager> dal vostro browser.
5. Inserire i dati di configurazione per collegarsi al database.
6. Procedere all'installazione del software, cliccando sul pulsante **Installa**.
**Attenzione**: è possibile che l'installazione richieda del tempo. Si consiglia pertanto di attendere almeno qualche minuto senza alcun cambiamento nella pagina di installazione (in particolare, della progress bar presente) prima di cercare una possibile soluzione nelle discussioni del forum o nella sezione dedicata.
### Versioni
Per mantenere un elevato grado di trasparenza riguardo al ciclo delle release, seguiamo le linee guida [Semantic Versioning (SemVer)](http://semver.org/) per definire le versioni del progetto.
Per vedere tutte le versioni disponibili al download, visitare la [pagina relativa](https://github.com/devcode-it/openstamanager/releases) su GitHub (per versioni precedenti alla 2.3, visitare [SourceForge](https://sourceforge.net/projects/openstamanager/files)).
Nel caso utilizziate il programma per uso commerciale, si consiglia di scaricare le release disponibili nel sito ufficiale del progetto (<http://www.openstamanager.com>), evitando di utilizzare direttamente il codice della repository.
Se siete inoltre interessati a supporto e assistenza professionali, li potete richiedere nella [sezione dedicata](http://www.openstamanager.com/per-le-aziende/).
### GitHub
Nel caso si stia utilizzando la versione direttamente ottenuta dalla repository di GitHub, è necessario eseguire i seguenti comandi da linea di comando per completare le dipendenze PHP (tramite [Composer](https://getcomposer.org)) e gli assets (tramite [Yarn](https://yarnpkg.com)) del progetto.
```bash
php composer.phar install
yarn global add gulp
yarn install
gulp
```
In alternativa alla sequenza di comandi precedente, è possibile utilizzare il seguente comando (richiede l'installazione di GIT e Yarn, oltre che l'inserimento dell'archivio `composer.phar` nella cartella principale del progetto):
```bash
yarn run develop-OSM
```
Per ulteriori informazioni, visitare le sezioni [Assets](https://devcode-it.github.io/openstamanager/assets.html) e [Framework](https://devcode-it.github.io/openstamanager/framework.html) della documentazione.
## Strumenti utili
### Windows
Per installare il server web si consiglia di scaricare [WAMP dal sito ufficiale](http://www.wampserver.com/en/#download-wrapper), seguendo l'installazione guidata senza particolari personalizzazioni.
Una volta terminata linstallazione è necessario creare una cartella per il gestionale in `C:\wamp\www\`, copiando al suo interno il contenuto della release scaricata.
### Linux
Per installare il web server è necessario installare i pacchetti `apache2`, `php5` e `mysql-server`.
```bash
sudo apt-get install apache2 php5 mysql-server
```
Una volta completata linstallazione è necessario creare una cartella per il gestionale, copiandobi al suo interno il contenuto della release scaricata, nel web server di Apache2:
- nella versione &lt;= 2.3, la cartella si trova in `/var/www/`;
- nella versione >= 2.4, la cartella si trova in `/var/www/html/`;
E' inoltre necessario assicurarsi di concedere i permessi di scrittura sulla cartella creata:
```bash
sudo chmod 777 -R /var/www/
```
Si consiglia l'installazione del pacchetto `phpmyadmin`, per poter gestire graficamente il database MySQL:
```bash
sudo apt-get install phpmyadmin
```
### MAC
La piattaforma Apple non è stata oggetto di molti test: pertanto si consiglia di individuare in prima persona un server web funzionante e con caratteristiche corrispondenti ai requisiti indicati.
Il gestionale è stato testato con successo su Mac OS X con [MAMP](http://www.mamp.info/en/) e XAMPP.
## Problemi comuni
### Schermata bianca
**Attenzione**: a partire dalla versione 2.3 questo problema non è più presente.
Nel caso si verifichi il problema di schermata bianca iniziale è necessario controllare i valori delle variabili `$rootdir` e `$docroot` nelle prime righe di _core.php_. Una possibile soluzione, implementata dalla versione 2.3, potrebbe essere:
```php
$docroot = __DIR__;
$rootdir = substr($_SERVER['SCRIPT_NAME'], 0, strrpos($_SERVER['SCRIPT_NAME'], '/')).'/';
if (strrpos($rootdir, '/'.basename($docroot).'/') !== false) {
$rootdir = substr($rootdir, 0, strrpos($rootdir, '/'.basename($docroot).'/')).'/'.basename($docroot);
} else {
$rootdir = '/';
}
$rootdir = rtrim($rootdir, '/');
$rootdir = str_replace('%2F', '/', rawurlencode($rootdir));
```
Si ricorda comunque che:
- `$docroot` deve corrispondere al percorso reale nel file system per raggiungere la cartella principale del gestionale.
- `$rootdir` deve corrispondere al percorso URL del browser per raggiungere il gestionale nel server web.
### Blocco dell'installazione (0%)
**Attenzione**: a partire dalla versione 2.3 questo problema non è più presente.
Nel caso l'installazione iniziale del database si blocchi allo 0% è necessario effettuare la seguente modifica nelle righe 15, 16 e 17 del file `lib\dbo.class.php` (https://www.openstamanager.com/forum/viewtopic.php?f=4&t=88353#p93976):
```php
if(@mysql_select_db($db_name, $conn)) {
@mysql_query("SET sql_mode = ''");
return "ok";
} else
```
Eventualmente, se questo primo passaggio si rivelasse non funzionante, si può procedere alla modifica delle impostazioni del DBMS (file `my.ini` di MySQL).
```ini
#sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
sql-mode="NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION"
```
La riga iniziante da `#` è quella originale, mentre quella seguente è l'opzione che permette il corretto funzionamento dell'installazione.
Discussioni originali:
- [\[RISOLTO\] Tabelle Mancanti](http://www.openstamanager.com/forum/viewtopic.php?f=2&t=86981)
- [MySQL running in Strict Mode and giving me problems. How to fix this?](http://stackoverflow.com/questions/21667601/mysql-running-in-strict-mode-and-giving-me-problems-how-to-fix-this)

View File

@ -1,53 +0,0 @@
---
currentMenu: home
---
# OpenSTAManager - Documentazione
Benvenuti nella wiki di OpenSTAManager!
> Al giorno d'oggi, per le aziende coinvolte nel settore dell'assistenza tecnica la necessità di un software dedicato, flessibile, completo e funzionale in molteplici categorie di dispositivi risulta di fondamentale importanza per permettere un'efficiente gestione dell'attività lavorativa.
> Per rispondere a queste esigenze nasce il gestionale per il servizio di assistenza tecnica OpenSTAManager, che rende disponibile un supporto informatico per la gestione di questa tipologia di pratiche in un contesto talvolta povero di alternative.
La documentazione del progetto presenta informazioni valide a partire dalla versione 2.3 dello stesso.
Si avverte pertanto che questa documentazione non è utilizzabile con efficacia per le versioni precedenti del progetto, con particolare riguardo verso le strutture relative ad assets e framework, oltre che alle procedure di sviluppo dei moduli.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Presentazione](#presentazione)
- [Storia](#storia)
- [Sviluppatori](#sviluppatori)
<!-- /TOC -->
## Presentazione
Il gestionale OpenSTAManager è un software open-source e web based, sviluppato dall'azienda informatica DevCode di Este per gestire ed archiviare il servizio di assistenza tecnica e la relativa fatturazione.
Il nome del progetto deriva dalla parziale traduzione in inglese degli elementi principali che lo compongono: la natura open-source e il suo obiettivo quale Gestore del Servizio Tecnico di Assistenza.
Un software gestionale, identificato nell'insieme degli applicativi che automatizzano i processi di gestione all'interno delle aziende, appartiene solitamente a una specifica categoria del settore, specializzata negli ambiti di:
- Gestione della contabilità;
- Gestione del magazzino;
- Gestione e ausilio della produzione;
- Gestione e previsione dei budget aziendali;
- Gestione ed analisi finanziaria.
Secondo questa definizione, OpenSTAManager riesce a generalizzare al proprio interno le funzionalità caratteristiche della contabilità e della gestione del magazzino, presentando inoltre moduli piuttosto avanzati e destinati a complementare l'attività aziendale in relazione agli interventi di assistenza della realtà lavorativa in oggetto.
## Storia
OpenSTAManager viene inizialmente ideato da Nicoletta Marampon e sviluppato da **Fabio Lovato** al fine di gestire esclusivamente le anagrafiche e gli interventi aziendali per piccole realtà lavorative.
La prima release (0.2RC2 dell'agosto 2008) viene successivamente ampliata con numerosi e innovativi componenti, quali il calendario delle attività, e ottimizzata in relazione al sistema di installazione e di aggiornamento; parallelamente, tra il 2011 e 2012, viene introdotto il sistema di gestione della contabilità e vengono migliorati numerosi moduli, soprattutto a livello grafico.
Fondamentale in questo senso risulta essere la collaborazione dei nuovi colleghi **Luca Salvà** e **Fabio Piovan**, che ha permesso il continuo adeguamento del progetto a un mondo informatico in continua evoluzione e a richieste sempre più complesse da parte dei clienti.
L'insieme di cambiamenti introdotti nel periodo compreso tra giugno 2016 e giugno 2017 hanno infine portato alla generazione di un ramo di sviluppo parallelo (_branch_) per la versione 2.3, destinata a cambiare e migliorare in modo fondamentale numerose sezioni _front-end_ e _back-end_ del progetto.
## Sviluppatori
- **Fabio Lovato**, il fondatore ([loviuz](https://github.com/loviuz))
- **Fabio Piovan** ([fpsoftware](https://github.com/fpsoftware))
- **Luca Salvà** ([lucasalva87](https://github.com/lucasalva87))
- **Matteo Baccarin**
- **Thomas Zilio** ([Dasc3er](https://github.com/Dasc3er))

View File

@ -1,105 +0,0 @@
---
currentMenu: assets
---
# Assets
> Web assets are things like CSS, JavaScript and image files that make the frontend of your site look and work great.
>
> \-- <cite>[Symfony](http://symfony.com/doc/current/best_practices/web-assets.html)</cite>
Gli assets sono, allinterno dei moderni ambienti di sviluppo web, il cuore pulsante del software in relazione al layout e al livello di accessibilità; in particolare,il termine assets fa solitamente riferimento ai componenti di natura grafica di un software, quali immagini, fonts e icone, linguaggi di scripting client-side (JavaScript) e fogli di stile a cascata (_Cascading Style Sheets_).
Il progetto utilizza [Yarn](https://yarnpkg.com/) per gestire l'installazione e l'aggiornamento degli assets e [Gulp](http://gulpjs.com/) per compilarli e associarli con le personalizzazioni. Viene inoltre richiesta la presenza di [Git](https://git-scm.com/) asll'interno del sistema operativo.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Struttura](#struttura)
- [Personalizzazione](#personalizzazione)
- [Tema grafico](#tema-grafico)
- [Aggiornamento e installazione pacchetti](#aggiornamento-e-installazione-pacchetti)
- [Compilazione](#compilazione)
- [Assets predefiniti](#assets-predefiniti)
<!-- /TOC -->
## Struttura
Yarn salva automaticamente gli assets da lui gestiti all'interno della cartella `node_modules`, non presente nella repository e nelle release del progetto per la sua natura estremamente variabile e facilmente riproducibile (tramite l'utilizzo dello strumento, come si vedrà in [Personalizzazione](#personalizzazione)).
Gli assets personalizzati del progetto sono al contrario contenuti all'interno della cartella `assets/src`; parallelamente, gli assets utilizzati direttamente dal progetto sono infine contenuti all'interno della cartella `assets/dist`, generata in automatico tramite l'utilizzo di [Gulp](http://gulpjs.com/).
## Personalizzazione
L'introduzione di una gestione automatizzata rende, di fatto, maggiromente semplificata la gestione delle dipendeze grafiche del progetto, portando però al tempo stesso alla necessità di utilizzare una specifica procedura per aggiornare e personalizzare gli assets.
Si ricorda che è altamente sconsigliato modificare i contenuti delle cartelle `node_modules` o `assets/dist` in modo manuale, poiché tali modifiche andrebbero perse a seguito di ogni aggiornamento.
### Tema grafico
La personalizzazione dello stile del gestionale può essere effettuata a partire dal foglio di stile `assets/src/css/themes/default.css`, contentente le principali impoistazioni grafiche del progetto.
L'aggiunta di un nuovo tema richieda la creazione di un file indipendente nella stessa cartella, rinominando la classe CSS generica con il nome della skin inserita (da `.skin-default` a `.skin-nome`).
Una volta eseguita la task automatica di compilazione, il nuovo file varrà aggiunto in `themes.min.css` di `assets/css`.
Per modificare lo stile utilizzato dal gestionale, vedere la variabile `$theme` in `config.inc.php`.
### Aggiornamento e installazione pacchetti
Nel caso si rivelasse necessario installare o aggiornare i pacchetti predisposti dal gestionale, è necessario procedere all'esecuzione dei comdani caratteristici di Yarn e successivamente eseguire una compliazione degli assets.
L'installazione di nuovi pacchetti viene eseguita attraverso il seguente comando:
```bash
yarn add <package>
```
L'aggiornamento degli assets gestiti è effettuabile tramite il seguente comando:
```bash
yarn upgrade
```
Per ulteriori informazioni, consultare la [documentazione ufficiale di Yarn](https://yarnpkg.com/en/docs).
### Compilazione
Per compilare gli assets, sia quelli gestiti da Yarn che quelli personalizzati, è necessario eseguire il seguente comando:
```bash
yarn run build-OSM
```
**Attenzione**: la compilazione è fondamentale a seguito di ogni modifica degli assets, poiché altrimenti i file utilizzati dal progetto non saranno aggiornati.
## Assets predefiniti
- admin-lte
- autosize
- bootstrap
- bootstrap-colorpicker
- bootstrap-daterangepicker
- ckeditor
- components-jqueryui
- datatables.net-bs
- datatables.net-scroller-bs
- eonasdan-bootstrap-datetimepicker
- font-awesome
- fullcalendar
- inputmask
- jquery
- jquery-form
- jquery-slimscroll
- jquery-ui-touch-punch
- moment
- parsleyjs
- promise-polyfill
- select2
- select2-bootstrap-theme
- signature_pad
- smartwizard
- sweetalert2
- tooltipster
_I nomi sono indicati secondo la notazione tipica dei pacchetti NPM._

View File

@ -1,73 +0,0 @@
---
currentMenu: framework
---
# Framework
> Un framework, termine della lingua inglese che può essere tradotto come intelaiatura o struttura, in informatica e specificatamente nello sviluppo software, è un'architettura logica di supporto (spesso un'implementazione logica di un particolare design pattern) su cui un software può essere progettato e realizzato, spesso facilitandone lo sviluppo da parte del programmatore.
>
> \-- <cite>[Wikipedia](https://it.wikipedia.org/wiki/Framework)</cite>
Il progetto utilizza [Composer](https://getcomposer.org/) per gestire le librerie PHP in modo completamente gratuito e open-source. Questo permette di completare l'installazione e l'aggiornamento dei diversi framework in modo facile ed intuitivo, senza doversi preoccupare in modo eccessivo delle dipendenze delle diverse librerie.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Struttura](#struttura)
- [Personalizzazione](#personalizzazione)
- [Aggiornamento](#aggiornamento)
- [Installazione di nuovi pacchetti](#installazione-di-nuovi-pacchetti)
- [Framework predefiniti](#framework-predefiniti)
<!-- /TOC -->
## Struttura
I framework vengono automaticamente scaricati da Composer all'interno della cartella _vendor_ nella root del progetto, dove vengono memorizzati secondo un percorso derivante dall'origine del pacchetto (per maggiori informazioni, consultare la [documentazione ufficiale di Composer](https://getcomposer.org/doc/)).
La modifica dei contenuti di `vendor` è altamente sconsigliata, poichè qualunque aggiornamento potrebbe sovrascrivere ed annullare le modifiche effettuate.
## Personalizzazione
Nel caso si rivelasse necessario aggiornare i framework presenti o installare nuove librerie, è necessario avere disponibile una corretta e funzionante [installazione locale di Composer](https://getcomposer.org/download/).
Una volta completata l'installazione di Composer è possibile, partendo dalla cartella del gestionale, iniziare l'aggiornamento e la personalizzazione tramite le seguenti operazioni.
### Aggiornamento
L'aggiornamento dei framework è effettuabile tramite il seguente comando:
```bash
php composer.phar update
```
Per ulteriori informazioni, consultare la [documentazione ufficiale di Composer](https://getcomposer.org/doc/).
### Installazione di nuovi pacchetti
Per installare nuovi framework e/o librerie è utilizzabile il seguente comando:
```bash
php composer.phar require <package>
```
Per ulteriori informazioni, consultare la [documentazione ufficiale di Composer](https://getcomposer.org/doc/).
## Framework predefiniti
- danielstjules/stringy
- ezyang/htmlpurifier
- filp/whoops
- ifsnop/mysqldump-php
- intervention/image
- ircmaxell/password-compat
- maximebf/debugbar
- monolog/monolog
- mpdf/mpdf
- paragonie/random_compat
- phpmailer/phpmailer
- spipu/html2pdf
- symfony/filesystem
- symfony/finder
- symfony/translation
_I nomi sono indicati secondo la notazione tipica dei progetti pubblici su GitHub._

View File

@ -1,155 +0,0 @@
---
currentMenu: api
---
# API
> Con application programming interface (in acronimo API, in italiano interfaccia di programmazione di un'applicazione), in informatica, si indica ogni insieme di procedure disponibili al programmatore, di solito raggruppate a formare un set di strumenti specifici per l'espletamento di un determinato compito all'interno di un certo programma.
>
> \-- <cite>[Wikipedia](https://it.wikipedia.org/wiki/Application_programming_interface)</cite>
L'API del progetto è attualmente ancora in sviluppo, e pertanto le funzioni disponibili potrebbero essere piuttosto ridotte.
Di seguito sono elencate le basi per connettersi al sistema e ottenere i dati a cui si è interessati.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Requisiti aggiuntivi](#requisiti-aggiuntivi)
- [Standard di comunicazione](#standard-di-comunicazione)
- [Ottenere la chiave](#ottenere-la-chiave)
- [Formato dei componenti](#formato-dei-componenti)
- [Output](#output)
- [Stati](#stati)
- [Lettura](#lettura)
- [Personalizzazione](#personalizzazione)
- [Richieste di lettura](#richieste-di-lettura)
- [Interventi](#interventi)
- [Anagrafiche](#anagrafiche)
- [Richieste disabilitate](#richieste-disabilitate)
- [Modifiche](#modifiche)
- [Eliminazioni](#eliminazioni)
<!-- /TOC -->
## Requisiti aggiuntivi
Per rendere la gestione dell'API maggiormente mantenibile e unificata, il suo funzionamento è stato sottoposto al seguente requisito aggiuntivo:
- MySQL >= 5.6.5
Se queste requisito non viene soddisfatto, l'installazione del gestionale procederà correttamente, ma i tentativi di connessione con l'API saranno rifiutati con il codice di errore `503` e lo stato `Servizio non disponibile`.
Nel caso, a seguito dell'installazione di OpenSTAManager, venisse aggiornato il servizio MySQL per permettere il funzionamento dell'API, sarà necessaro causare l'esecuzione della procedura di aggiornamento del gestionale, che organizzarà correttamente il database per la compatibilità con l'API.
**Attenzione**: il solo aggiornamento del servizio MySQL senza il successivo aggiornamento del gestionale potrebbe causare malfunzionamenti di vario genere nell'utilizzo dell'API.
## Standard di comunicazione
Il funzionamento dell'API si basa fondamentalmente sull'utilizzo di una chiave di accesso univoca per ogni dispositivo, ospitata all'interno della tabella `zz_tokens` del database del progetto.
Ogni richiesta all'API deve contenere la chiave di accesso (campo `token`) e l'operazione richiesta (campo `resource`), inserendo questi elementi tra gli ulteriori contenuti che si intendono inviare.
I contenuti della richiesta devono quindi essere convertiti in formato JSON ed inviati all'API secondo uno specifico schema:
- `POST` - Richieste di creazione (**Create**).
- `GET` - Richieste di informazioni (**Retrieve**).
- `PUT` - Richieste di modifica (**Update**).
- `DELETE` - Richieste di eliminazione (**Delete**).
### Ottenere la chiave
La chiave di accesso può essere ottenuta sfruttando l'operazione di accesso nativa dell'API, che prevede l'invio di una richiesta **POST** corrispondente alla seguente struttura:
- `resource` - login.
- `username` - &lt;username dell'account>.
- `password` - &lt;password dell'account>.
### Formato dei componenti
I seguenti componenti delle richieste devono seguire una rigida struttura:
- `page` - intero.
- `upd` - yyyy-MM-dd hh:mm:ss.
## Output
L'API del progetto permette di ottenere le informazioni attraverso un array in formato JSON.
### Stati
Ogni richiesta effettuata all'API viene accompagnata da un messaggio predefinito che permette di interpretare in modo più preciso la risposta.
In particolare, sono presenti i seguenti _status_:
- `200: OK` - La richiesta è andata a buon fine.
- `400: Errore interno dell'API` - La richiesta effettuata risulta invalida per l'API.
- `401: Non autorizzato` - Accesso non autorizzato.
- `404: Non trovato` - La risorsa richiesta non risulta disponibile.
- `500: Errore del server` - Il gestionale non è in grado di completare la richiesta.
- `503: Servizio non disponibile` - L'API del gestionale non è abilitata.
### Lettura
Le richieste di lettura sono solitamente completate con un numero predefinito di informazioni.
Per poter interpretare correttamente i dati, si devono sfruttare in particolare i seguenti campi generici:
- `records`: elenco dei record presenti nella pagina richiesta (parametro `page`);
- `total-count`: numero totale dei record;
- `pages`: numero della pagine disponibili.
Si ricorda che l'API prevede la restituzione di un insieme di dati limitato rispetto alla richiesta effettuatua: per ottenere l'intero insieme di informazioni è necessario eseguire molteplici richieste consecutive basate sul campo `page`.
La lunghezza delle pagine dell'API viene definita dall'impostazione *Lunghezza pagine per API*, modificabile esclusivamente all'interno della tabella `zz_settings`.
## Personalizzazione
L'API sfrutta una struttura modulare per poter funzionare in modo completo e garantire al tempo stesso il possibile ampliamento delle sue funzioni.
In particolare, ogni modulo può specificare una determinata serie di operazioni che lo riguardano e che possono essere richiamate in vari modi.
Di seguito lo schema attraverso cui l'API individua la presenza delle possibili richieste supportate dai moduli (cartelle **api/** e **custom/api/**):
- `POST` - File `create.php`.
- `GET` - File `retrieve.php`.
- `PUT` - File `update.php`.
- `DELETE` - File `delete.php`.
## Richieste di lettura
### Interventi
Tutto il contenuto della tabella in_interventi:
http://<url_osm>/api/?token=<token>&resource=in_interventi
Singolo intervento (riga della tabella):
http://<url_osm>/api/?token=<token>&resource=in_interventi&filter[id]=[1]
### Anagrafiche
Tutto il contenuto della tabella an_anagrafiche:
http://<url_osm>/api/?token=<token>&resource=an_anagrafiche
Singolo intervento (riga della tabella):
http://<url_osm>/api/?token=<token>&resource=an_anagrafiche&filter[idanagrafica]=[1]
Ricerca per ragione sociale:
http://<url_osm>/api/?token=<token>&resource=an_anagrafiche&filter[ragione_sociale]=[%<stringa_ragione_sociale>%]
### Richieste disabilitate
#### Modifiche
Tutti i contenuti di tutte le tabelle:
http://<url_osm>/api/?token=<token>&resource=updates
Tutti i contenuti di tutte le tabelle, aggiornati a partire da una data precisa:
http://<url_osm>/api/?token=<token>&resource=updates&upd=2016-01-31%2010:44:31
#### Eliminazioni
Tutte le eliminazioni di tutte le tabelle:
http://<url_osm>/api/?token=<token>&resource=deleted

View File

@ -1,29 +0,0 @@
---
currentMenu: extra
---
# Extra
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Campi personalizzati](#campi-personalizzati)
- [Messaggi personalizzati](#messaggi-personalizzati)
<!-- /TOC -->
## Campi personalizzati
A partire dalla versione 2.4 è possibile sfruttare dei campi personalizzati per aggiungere informazioni ai moduli principali in modo dinamico.
Questi campi sono gestiti a livello di database attarverso le tabelle `zz_fields` e `zz_field_record`, che si occupano riespettivamente della gestione generale dei campi e del salvataggio dei record personalizzati.
Le procedure automatiche di gestione di questi campi sono integrate nei file `actions.php`, `editor.php` e `add.php`.
E' eventualmente disponibile il modulo **Campi personalizzati**, da abilitare, per la gestione dinamica di queste informazioni.
## Messaggi personalizzati
A partire dalla versione 2.4.2 è stato reso possibile inserire dei messaggi, specifici per l'installazione in utilizzo, presenti in ogni pagina del gestionale.
E' possibile procedere alla personalizzazione di questi contenuti attraverso i seguenti file (da creare secondo necessità):
- `include/custom/extra/login.php`, dedicato ai messaggi da mostrare all'accesso
- `include/custom/extra/extra.php`, per i messaggi da mostrare una volta che l'utente si è autenticato

View File

@ -1,236 +0,0 @@
---
currentMenu: nucleo
---
# Struttura
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Struttura](#struttura)
- [Root](#root)
- [add.php](#addphp)
- [ajax_complete.php](#ajaxcompletephp)
- [ajax_dataload.php](#ajaxdataloadphp)
- [ajax_select.php](#ajaxselectphp)
- [bug.php](#bugphp)
- [core.php](#corephp)
- [config.inc.php](#configincphp)
- [controller.php](#controllerphp)
- [editor.php](#editorphp)
- [index.php](#indexphp)
- [info.php](#infophp)
- [log.php](#logphp)
- [composer.json, gulpfile.js, package.json](#composerjson-gulpfilejs-packagejson)
- [Cartella api](#cartella-api)
- [Cartella assets](#cartella-assets)
- [Cartella backup](#cartella-backup)
- [Cartella docs](#cartella-docs)
- [Cartella files](#cartella-files)
- [Cartella include](#cartella-include)
- [bottom.php](#bottomphp)
- [top.php](#topphp)
- [Cartella lib](#cartella-lib)
- [deprecated.php](#deprecatedphp)
- [functions.php](#functionsphp)
- [functionsjs.php](#functionsjsphp)
- [init.js](#initjs)
- [Cartella locale](#cartella-locale)
- [Cartella modules](#cartella-modules)
- [Cartella templates](#cartella-templates)
- [Cartella update](#cartella-update)
- [create_updates.sql](#createupdatessql)
- [VERSIONE.sql](#versionesql)
- [VERSIONE.php](#versionephp)
- [Cartella vendor](#cartella-vendor)
<!-- /TOC -->
## Struttura
Scaricando la versione GIT del progetto dovreste trovare una struttura di base molto simile a quella seguente.
.
├── api
├── assets
├── backup
├── doc
├── files
├── include
├── lib
├── locale
├── modules
├── src
├── templates
├── update
└── vendor
Analizzeremo ora in dettaglio la funzione delle diverse cartelle e dei relativi contenuti.
Si avverte che il gestionale è fortemente basato sulla correttezza contemporanea di molti file: siete pertanto pregati di astenervi da modifiche o, se queste dovessero rivelarsi necessarie, procedere alla creazione di un relativo file custom nella cartella del file.
E' comunque consigliabile richiedere l'assistenza ufficiale.
Per maggiori informazioni riguardanti la procedura di personalizzazione, rivolgersi alle specifiche sezioni di ogni settore.
## Root
I contenuti della cartella _root_ sono estremamente importanti per il progetto, in quanto sono generalmente dedicati a garantire il corretto funzionamento dell'intero gestionale.
Questa centralizzazione permette al software di essere estremamente scalabile e personalizzabile, soprattutto in relazione ai moduli.
Per maggiori informazioni riguardanti lo sviluppo di un modulo, consultare la sezione [Moduli](Moduli.md).
### add.php
Il file `add.php` è dedicato alla gestione dei form di creazione nuovi elementi all'interno dei vari moduli.
In particolare si occupa parallelamente della funzionalità di aggiunta al volo, visibile in azione nei modulo **Interventi**, **Articoli** e in alcuni altri punti del software.
### ajax_complete.php
Il file `ajax_dataload.php` gestisce il caricamento dinamico dei dati in varie sezioni del sito, relativamente alle operazioni di auto-completamento dei form e della ricerca globale.
**Attenzione**: questo sistema è ormai deprecato e, tranne in rari casi, completamente sostituito dall'utilizzo del file `ajax_select.php` e dal plugin [Select2](https://select2.github.io/).
### ajax_dataload.php
Il file `ajax_dataload.php` gestisce il caricamento dinamico dei dati nelle tabelle fornite nella vista generale dei moduli (`controller.php`), filtrando i risultati in base alle richieste dell'utente.
### ajax_select.php
Il file `ajax_select.php` gestisce il caricamento dinamico dei dati nei diversi select abilitati, garantendo l'accesso a tutti i record senza provocare rallentamenti (persino per numeri più elevati).
### bug.php
Il file `bug.php` si occupa della segnalazione dei bug, fornendo un sistema integrato di invio email dopo la configurazione di pochi parametri iniziali.
Le opzioni relative alle informazioni da allegare sono:
- Allegare il file di log (fondamentale nel caso si stia effettuando una segnalazione)
- Allegare una copia del database
- Allegare le informazioni relative al PC utilizzato
### core.php
Il _core_ contiene il nucleo dell'intero gestionale: si occupa delle operazioni di inizializzazione fondamentali, compresa l'inclusione del file di configurazione `config.inc.php` e la creazione dell'elenco degli assets da includere.
Si occupa inoltre del controllo dei permessi, tramite il richiamo alla specifica classe `Permissions`, e dell'individuazione delle informazioni di base relative al modulo in utilizzo.
### config.inc.php
Il file `config.inc.php` contiene tutte le informazioni per accedere correttamente al database e per determinare il tema utilizzato dal gestionale.
**Attenzione**: questo file non è presente di default poiché obbligatoriamente da personalizzare tramite la procedura di installazione.
La struttura di base può essere comunque osservata all'interno del file `config.example.php`.
### controller.php
Il file `controller.php` si occupa di gestire l'accesso generico ai moduli, caricando le informazioni e i widget del modulo in oggetto.
Permette inoltre la visualizzazione, in base ai permessi accordati all'utente, del pulsante di creazione nuovi elementi.
### editor.php
Il file `editor.php` si occupa di gestire l'accesso specifico ai dati di un singolo elemento di un modulo, caricando al tempo stesso l'insieme di plugin (e, in casi più rari, di widget) legati alla visualizzazione dell'elemento in oggetto.
Permette inoltre, in base ai permessi accordati all'utente, la modifica dei dati inseriti e l'interazione con altri moduli.
### index.php
Il file `index.php` si occupa delle operazioni di accesso e scollegamento al gestionale, oltre che effettuare un controllo sulla disponibilità di aggiornamenti (tramite l'inclusione di `include/update.php`) e a garantire il redirect iniziale al primo modulo su cui l'utente possiede i permessi di accesso.
### info.php
Il file `info.php` contiene la sezione informativa relativa al progetto, indicante la community, la modalità di supporto e le offerte a pagamento.
### log.php
Il file `log.php` permette di visualizzare le informazioni relative agli ultimi 100 tentativi di accesso.
**Attenzione**: nel caso in cui l'utente sia un amministratore, le informazioni accessibili sono relative a **tutti** gli utenti (al contrario, un utente normale può visualizzare esclusivamente i propri tentativi).
### composer.json, gulpfile.js, package.json
Per maggiori informazioni questi file, consultare le sezioni [Framework](Framework.md) e [Assets](Assets.md).
## Cartella api
Per maggiori informazioni riguardanti la cartella `api` e i suoi contenuti, rivolgersi alla sezione [API](API.md).
## Cartella assets
Per maggiori informazioni riguardanti la cartella `assets` e i suoi contenuti, rivolgersi alla sezione [Assets](Assets.md).
## Cartella backup
La cartella _backup_ è quella di default utilizzata dall'operazione omonima del progetto.
## Cartella docs
La cartella `docs`, come si può intuire, contiene la documentazione di sviluppo del progetto.
## Cartella files
Per maggiori informazioni riguardanti la cartella `files` e i suoi contenuti, rivolgersi alla sezione [Moduli](Moduli.md).
## Cartella include
### bottom.php
Il file `bottom.php` si occupa delle operazioni di chiusura della pagina HTML, garantendo inoltre l'eliminazione dei log temporanei della sessione.
Si ricorda che è possibile creare una personalizzazione di questa pagina nella cartella `custom`.
### top.php
Il file `top.php` gestisce la creazione del layout di base del gestionale, comprendente la barra di navigazione e la sidebar.
Si ricorda che è possibile creare una personalizzazione di questa pagina nella cartella `custom`.
## Cartella lib
La cartella `lib` contiene le librerie personalizzate e le funzioni utilizzate dall'intero gestionale nei diversi moduli.
**Attenzione**: sono qui presenti solo i metodi generali e comunemente riutilizzati.
Per maggiori informazioni riguardanti la locazione delle funzioni specifiche di un modulo, visitare la sezione [Moduli](Moduli.md).
### deprecated.php
Il file `deprecated.php` contiente l'insieme di funzioni deprecate nella versione corrente del gestionale, che verranno successivamente rimosse nella futura release.
### functions.php
Il file `functions.php` contiene tutte le funzioni comunemente utilizzate nel progetto.
### functionsjs.php
Il file `functionsjs.php` contiene tutte le funzioni JavaScript comunemente utilizzate nel progetto.
### init.js
Il file `init.js` contiene le funzioni JavaScript comunemente richiamate al caricamento di parti indipendenti del progetto.
## Cartella locale
La cartella `locale` contiene tutte le traduzioni del progetto, nei formati tipici di Gettext (`.po` e `.mo`).
## Cartella modules
Per maggiori informazioni riguardanti la cartella `modules` e i suoi contenuti, rivolgersi alla sezione [Moduli](Moduli.md).
Si ricorda che per tutti i contenuti del modulo è possibile creare una personalizzazione nella cartella `custom`.
## Cartella templates
La cartella `templates` contiene tutti i file relativi alla visualizzazione in PDF dei dati dei vari moduli.
Per maggiori informazioni riguardanti la cartella `templates` e i suoi contenuti, rivolgersi alla sezione [Stampe](Stampe.md).
## Cartella update
### create_updates.sql
Il file `create_updates.sql` contiene la query SQL per la creazione della tabella di gestione degli aggiornamenti e delle installazioni del gestionale.
### VERSIONE.sql
I file `VERSIONE.sql` contengono l'insieme di query SQL necessarie per l'aggiornamento del gestionale alla versione _VERSIONE_.
### VERSIONE.php
I file `VERSIONE.php` contengono l'insieme di operazioni PHP (e, talvolta, SQL) necessarie per l'aggiornamento del gestionale alla versione _VERSIONE_.
## Cartella vendor
Per maggiori informazioni riguardanti la cartella `vendor` e i suoi contenuti, rivolgersi alla sezione [Framework](Framework.md).

View File

@ -1,39 +0,0 @@
---
currentMenu: upload
---
# Gestione degli upload
Pagina in costruzione.
La cartella `files` viene utilizzata dal progetto per gestire in modo unificato contenuti di vario tipo per i moduli installati.
In generale, questa cartella è dedicata alla memorizzazione dei file di cui viene fatto l'upload attraverso la funzione fornita in automatico dal getionale, ma sono presenti delle specifiche personalizzazioni necessarie per l'adeguato funzionamento di alcuni moduli.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Modulo MyImpianti](#modulo-myimpianti)
<!-- /TOC -->
## Modulo MyImpianti
Il modulo **MyImpianti** sfrutta la propria cartella all'interno di `files` per gestire, oltre alle proprie immagini, le impostazioni (`.ini`) dei componenti disponibili.
I file `*.ini` devono seguire il seguente standard. {} = facoltativo
```ini
[Nome del campo]
tipo = tag_HTML
valore = {"Valore di default"}
{opzioni = "Opzione 1", "Opzione 2", "Opzione 3"}
[Nome del campo]
tipo = tag_HTML
valore = {"Valore di default"}
{opzioni = "Opzione 1", "Opzione 2", "Opzione 3"}
```
La dicitura "tag_HTML" indica la possibilità di inserire all'interno del campo il nome di un qualsiasi tag HTML per l'utilizzo durante la modifica.
In particolare, il gestionale supporta la maggior parte dei campi HTML di input (input, select, textarea, date, ...); se necessario, è inoltre possibile (span, p, ...).
Il file `my_impianti/componente.ini` è un esempio di base di questa funzionalità, e un'ulteriore personalizzazione può essere trovata [nel forum](http://www.openstamanager.com/forum/viewtopic.php?f=5&t=93).

View File

@ -1,283 +0,0 @@
---
currentMenu: moduli
---
# Moduli
> Un modulo (software) è un componente software autonomo e ben identificato, e quindi facilmente riusabile.
>
> \-- <cite>[Wikipedia](https://it.wikipedia.org/wiki/Modulo#Informatica)</cite>
All'interno del progetto, i moduli vengono genericamente definiti quali sistemi di gestione delle funzionalità del gestionale; proprio per questo, la loro struttura e composizione risulta spesso variabile e differenziata.
Ogni modulo è composto da diverse sezioni, generalmente suddivise in:
- Nucleo;
- [Stampe](Stampe.md);
- [Widget](Widget.md);
- [Plugin](Plugin.md).
OpenSTAManager presenta inoltre una struttura nativamente predisposta alla personalizzazione delle funzioni principali, il che rende il progetto ancora più complicato da comprendere a prima vista.
Di seguito viene presentate le strutture principali più comuni supportate dal gestionale; per ulteriori approfondimenti, si consiglia di controllare il codice sorgente dei moduli ufficiali.
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Struttura](#struttura)
- [actions.php](#actionsphp)
- [add.php e edit.php](#addphp-e-editphp)
- [init.php](#initphp)
- [controller_after.php e controller_before.php](#controllerafterphp-e-controllerbeforephp)
- [modutil.php](#modutilphp)
- [Database](#database)
- [zz_modules](#zzmodules)
- [zz_permissions e zz_group_module](#zzpermissions-e-zzgroupmodule)
- [zz_views e zz_group_view](#zzviews-e-zzgroupview)
- [zz_plugins e zz_widgets](#zzplugins-e-zzwidgets)
- [Consigli per lo sviluppo](#consigli-per-lo-sviluppo)
- [Progettazione](#progettazione)
- [Sviluppo](#sviluppo)
- [Test](#test)
- [Installazione](#installazione)
- [Archivio ZIP](#archivio-zip)
- [update/VERSIONE.sql](#updateversionesql)
- [update/unistall.php](#updateunistallphp)
- [MODULE](#module)
- [Moduli di base](#moduli-di-base)
<!-- /TOC -->
## Struttura
Il codice sorgente di ogni modulo di OpenSTAManager è all'interno di un percorso univoco all'interno della cartella **modules**.
.
└── modules
└── modulo
   ├── actions.php
   ├── add.php
   ├── controller_after.php
   ├── controller_before.php
   ├── edit.php
   ├── init.php
   └── modutil.php
Il gestionale supporta in modo nativo questa struttura, che può essere ampliata e personalizzata secondo le proprie necessità: si consiglia pertanto di analizzare i moduli **Iva**, **Dashboard** e **Contratti** per esempi di diversa complessità.
> **Attenzione**: la presenza dei file sopra indicati è necessaria esclusivamente per i *moduli fisici*, cioè moduli che presentano la necessità di interagire con il codice sorgente e modificare i dati del gestionale.
>
> Per moduli presenti esclusivamente a livello di database (per sempio, **Movimenti**), si veda la sezione [Database](#database).
### actions.php
Il file `actions.php` gestisce tutte le operazioni supportate dal modulo.
In generale, le diverse operazioni vengono gestite attraverso attraverso una logica basata su casi (solitamente, il parametro `op` permette di identificare quale azione viene richiesta); il funzionamento a livello di programmazione può essere comunque sottoposto a scelte personali.
L'unico requisito effettivo risulta relativo alle operazioni di creazione dei nuovi record, per cui deve essere definito all'interno della variabile `$id_record` l'identificativo del nuovo elemento.
Per osservare questo sistema, si consiglia di analizzare il relativo file del modulo **Iva**.
### add.php e edit.php
Il file `add.php` contiene il template HTML dedicato all'inserimento di nuovi elementi per il modulo, mentre `edit.php` contiene il template HTML dedicato alla modifica degli stessi.
In base alla configurazione del modulo nel database, il file `edit.php` può assumere il ruolo di gestore della sezione principale dell'interno modulo.
Esempi di questa gestione si possono osservare nei moduli **Dashboard** e **Gestione componenti** (si veda la sezione [zz_modules](#zzmodules)).
> **Attenzione**: il progetto individua in automatico la presenza del file `add.php` e agisce di conseguenza per permettere o meno l'inserimento di nuovi record.
### init.php
Il file `init.php` si occupa di individuare le informazioni principali utili all'identificazione e alla modifica dei singoli elementi del modulo.
In particolare, questo file è solitamente composto da una query dedicata ad ottenere tutti i dati dell'elemento nella variabile `$record` (`$records` per versioni <= 2.4.1), successivamente utilizzata dal gestore dei template per completare le informazioni degli input.
### controller_after.php e controller_before.php
Il file `controller_before.php` contiene il template HTML da aggiungere all'inizio della pagina principale del modulo se questo è strutturato in modo tabellare.
Similmente, il file `controller_after.php` contiene il template HTML da aggiungere alla fine della pagina principale nelle stesse condizioni.
### modutil.php
Il file `modutil.php` viene utilizzato per definire le funzioni PHP specifiche del modulo, e permettere in questo modo una gestione semplificata delle operazioni più comuni.
Si noti che un modulo non è necessariamente limitato all'utilizzo del proprio file `modutil.php`: come avviene per esempio in **Fatture** e **Interventi**, risulta possibile richiamare file di questa tipologia da altri moduli (in questo caso, da **Articoli** per la gestione delle movimentazioni di magazzino).
## Database
All'interno del database del progetto, le tabelle con il suffisso `zz` sono generalmente dedicate alla gestione delle funzioni di base del gestionale.
La gestione dei moduli avviene in questo senso grazie alle seguenti tabelle:
- `zz_modules`;
- `zz_permissions`;
- `zz_views`;
- `zz_plugins`;
- `zz_widgets`.
### zz_modules
La tabella `zz_modules` contiene tutte le informazioni dei diversi moduli installati nel gestionale in uso, con particolare riferimento a:
- Nome (utilizzato a livello di codice) [`name`]
- Titolo (nome visibile e personalizzabile) [`title`]
- Percorso nel file system (partendo da `modules/`) [`directory`]
- Icona [`icon`]
- Posizione nella sidebar [`order`]
- Compatibilità [`compatibility`]
- Query di default [`options`]
- Query personalizzata [`options2`]
Gli ultimi due attributi si rivelano di fondamentale importanza per garantire il corretto funzionamento del modulo, poiché descrivono il comportamento dello stesso per la generazione della schermata principale nativa in OpenSTAManager.
Sono permessi i seguenti valori:
- custom [Modulo con schermata principale personalizzata e definita nel file `edit.php`]
- {VUOTO} [Menu non navigabile]
- menu [Menu non navigabile]
- Oggetto JSON
```json
{ "main_query": [ { "type": "table", "fields": "Nome, Descrizione", "query": "SELECT `id`, `nome` AS `Nome`, `descrizione` AS `Descrizione` FROM `tabella` WHERE 2=2 HAVING 1=1 ORDER BY `nome`"} ]}
```
- Query SQL \[vedasi la tabella [zz_views](#zz_views-e-zz_group_view)]
```sql
SELECT |select| FROM `tabella` WHERE 2=2 HAVING 1=1
```
### zz_permissions e zz_group_module
La tabella `zz_permissions` contiene i permessi di accesso dei vari gruppi ai diversi moduli, mentre la tabella `zz_group_module` contiene le clausole SQL per eventualmente restringere questo accesso.
### zz_views e zz_group_view
Le tabelle `zz_views` e `zz_group_view` vengono utilizzate dal gestionale per la visualizzazione delle informazioni secondo i permessi accordati, oltre che dal modulo **Viste** per la gestione dinamica delle query.
### zz_plugins e zz_widgets
La tabella `zz_plugins` contiene l'elenco di plugins relativi ai diversi moduli, mentre la tabella `zz_widgets` contiene l'elenco di widgets dei vari moduli.
## Consigli per lo sviluppo
### Progettazione
Alla base dello sviluppo di ogni modulo vi è una fase di analisi indirizzata all'individuazione dettagliata delle funzionalità dello stesso e della struttura interna al database atta a sostenere queste funzioni.
Siete dunque pregati di identificare chiaramente tutte le caratteristiche del Vostro nuovo modulo o delle Vostre modifiche prima di iniziare lo sviluppo vero e proprio (comunemente identificato con la scrittura del codice).
> E' bene trascurare le fasi di analisi e di progetto e precipitarsi all'implementazione allo scopo di guadagnare il tempo necessario per rimediare agli errori commessi per aver trascurato la fase di analisi e di progetto.
>
> \-- <cite>Legge di Mayers</cite>
### Sviluppo
Lo sviluppo del codice deve seguire alcune direttive generali per la corretta interpretazione del codice all'interno del gestionale: ciò comporta una struttura di base fondata sui file precedentemente indicati nella sezione [Struttura](#struttura) ma ampliabile liberamente.
### Test
Prima di pubblicare un modulo si consiglia di effettuare svariati test in varie installazioni.
Siete inoltre pregati di indicare i bug noti.
> Se cè una remota possibilità che qualcosa vada male, sicuramente ciò accadrà e produrrà il massimo danno.
>
> \-- <cite>Legge di Murphy</cite>
## Installazione
L'installazione di un modulo è completabile in modo automatico seguendo la seguente procedura:
- Scaricare l'archivio `.zip` del modulo da installare;
- Accedere al proprio gestionale con un account abilita all'accesso del modulo **Aggiornamenti**;
- Selezionare l'archivio scaricato nella selezione file della sezione "Carica un nuovo modulo";
- Cliccare il pulsante "Carica".
Si ricorda che per effettuare l'installazione è necessaria la presenza dell'estensione `php_zip` (per ulteriori informazioni guardare [qui](http://php.net/manual/it/zip.installation.php)).
> **Attenzione**: la procedura può essere completata anche a livello manuale, ma si consiglia di evitare tale sistema a meno che non si conosca approfonditamente il procedimento di installazione gestito da OpenSTAManager.
### Archivio ZIP
L'archivio del modulo deve essere organizzato secondo la seguente struttura:
modulo.zip
├── update
| ├── VERSIONE.sql
| └── unistall.php
├── ... - File contententi il codice del modulo
└── MODULE
Alcuni esempi sulla struttura dei moduli personalizzati sono disponibili nella repository https://github.com/devcode-it/example (download effettuabile da [qui](http://openstamanager.com/download/plugin_di_esempio.zip)).
#### update/VERSIONE.sql
Il file `VERSIONE.sql` (dove VERSIONE sta per la versione del modulo con `_`[underscore] al posto di `.`[punto]) contiene le operazioni di installazione e aggiornamento del modulo a livello del database, comprendenti la creazione delle tabelle di base del modulo e l'inserimento di ulteriori dati nelle altre tabelle.
#### update/unistall.php
Il file `unistall.php` contiene le operazioni di disinstallazione del modulo a livello del database, e deve prevedere l'eliminazione delle tabelle non più necessarie e dei dati inutilizzati.
```php
<?php
include_once __DIR__.'/../../core.php';
$dbo->query("DROP TABLE `tabella`");
```
#### MODULE
Il file `MODULE` è infine il diretto responsabile dell'installazione del modulo poiché definisce tutti i valori caratteristici dello stesso; in caso di sua assenza la cartella compressa viene considerata non corretta.
```ini
name = "Nome del modulo"
version = "Versione"
directory = "Cartella di installazione"
options = "Operazione da eseguire all'apertura"
compatibility = "Versioni di compatibilità"
compatibility = "Compatibilità del modulo"
parent = "Genitore del modulo"
```
## Moduli di base
Nella versione base del gestionale sono presenti, all'interno della cartella **modules**, i seguenti moduli.
.
├── aggiornamenti
├── anagrafiche
├── articoli
├── automezzi
├── backup
├── beni
├── categorie
├── causali
├── contratti
├── dashboard
├── ddt
├── fatture
├── gestione_componenti
├── interventi
├── impostazioni
├── iva
├── listini
├── misure
├── my_impianti
├── ordini
├── pagamenti
├── partitario
├── porti
├── preventivi
├── primanota
├── scadenzario
├── stati_intervento
├── tecnici_tariffe
├── tipi_anagrafiche
├── tipi_intervento
├── utenti
├── viste
├── voci_servizio
└── zone

View File

@ -1,50 +0,0 @@
---
currentMenu: plugin
---
# Plugin
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
- [Installazione](#installazione)
- [Archivio ZIP](#archivio-zip)
- [update](#update)
- [PLUGIN](#plugin)
<!-- /TOC -->
Pagina in costruzione.
## Installazione
### Archivio ZIP
L'archivio del modulo deve essere organizzato secondo la seguente struttura:
modulo.zip
├── ... - File contententi il codice del modulo
└── PLUGIN
Alcuni esempi sulla struttura dei moduli personalizzati sono disponibili nella repository https://github.com/devcode-it/example (download effettuabile da [qui](http://openstamanager.com/download/plugin_di_esempio.zip)).
#### update
Contrariamente ai moduli, i plugin non supportano la modifica del database in fase di installazione e aggiornamento.
#### PLUGIN
Il file `PLUGIN` è infine il diretto responsabile dell'installazione del modulo poiché definisce tutti i valori caratteristici dello stesso; in caso di sua assenza la cartella compressa viene considerata non corretta.
```ini
name = "Nome del plugin"
version = "Versione"
directory = "Cartella di installazione"
options = "Operazione da eseguire all'apertura"
icon = "Icona (Font-Awesome)"
compatibility = "Versioni di compatibilità"
module_from = "Nome del modulo di origine"
module_to = "Nome del modulo di destinazione e visualizzazione"
position = "Tipo di modulo (valori disponibili: tab)"
```

View File

@ -1,48 +0,0 @@
---
currentMenu: stampe
---
# Stampe
Pagina in costruzione.
- [MPDF](#mpdf)
- [HTML2PDF](#html2pdf)
- [Struttura](#struttura)
- [pdfgen.php](#pdfgenphp)
- [pdfgen_variables.php](#pdfgenvariablesphp)
- [Struttura interna](#struttura-interna)
## MPDF
**Attenzione**: come indicato nel secondo punto in http://mpdf.github.io/tables/auto-layout-algorithm.html, MPDF effettua un resizing del font nel caso il contenuto di una cella superi l'altezza totale di una pagina.
Fino a quel punto, il rendering funziona perfettamente.
Nel caso fosse per esempio aumentare le dimensioni del font, si consiglia di effettuare alcuni test per controllare se le tabelle vengono renderizzate nel modo corretto e previsto.
## HTML2PDF
### Struttura
La cartella _templates_ contiene tutti i template per la creazione dei PDF, raggruppati in base al nome del modulo. QUesti vengono utilizzati da `pdfgen.php` e da `pdfgen_variables.php` per la generazione vera e propria del PDF tramite il framework [HTML2PDF](https://github.com/spipu/html2pdf).
#### pdfgen.php
Il file `pdfgen.php` si occupa della formattazione dei contenuti dei template per la visualizzazione vera e propria del PDF, inizializzando l'oggetto relativo ed eseguendone l'output.
#### pdfgen_variables.php
Il file `pdfgen_variables.php` si occupa della sostituzione delle variabili comuni a tutti i template, e viene richiamata dal file `pdfgen.MODULO.php` descritto di seguito.
#### Struttura interna
La cartella _templates_ contiene tutti i template per la creazione dei PDF relativi al modulo specifico, in una struttura interna simile alla seguente (modulo **Contratti** utilizzato come esempio).
.
└── contratti
   ├── contratto_body.html - Struttura di base del PDF
   ├── contratto.html - Contenitore personalizzato della struttura del PDF
   ├── logo_azienda.jpg - Logo dell'azienda specifico per il PDF
   └── pdfgen.contratti.php - Individuazione delle informazioni da visualizzare e generazione della loro struttura

View File

@ -1,12 +0,0 @@
---
currentMenu: widget
---
# Widget
<!-- TOC depthFrom:2 depthTo:6 orderedList:false updateOnSave:true withLinks:true -->
<!-- /TOC -->
Pagina in costruzione.

View File

@ -1,13 +1,11 @@
<?php
include_once __DIR__.'/../../core.php';
$upload_dir = DOCROOT.'/'.Uploads::getDirectory($id_module, $id_plugin);
include_once __DIR__.'/init.php';
switch (filter('op')) {
case 'generate':
try {
$fattura = new Plugins\Fatturazione\FatturaElettronica($id_record);
if (!empty($fattura)) {
$file = $fattura->save($upload_dir);
flash()->info(tr('Fattura elettronica generata correttamente!'));
@ -15,18 +13,13 @@ switch (filter('op')) {
if (!$fattura->isValid()) {
flash()->warning(tr('La fattura elettronica potrebbe avere delle irregolarità!'));
}
} catch (UnexpectedValueException $e) {
} else {
flash()->error(tr('Impossibile generare la fattura elettronica'));
}
break;
case 'download':
try {
$fattura = new Plugins\Fatturazione\FatturaElettronica($id_record);
download($upload_dir.'/'.$fattura->getFilename());
} catch (UnexpectedValueException $e) {
}
download($upload_dir.'/'.$fattura->getFilename());
break;
}

View File

@ -1,17 +1,14 @@
<?php
include_once __DIR__.'/../../core.php';
include_once __DIR__.'/init.php';
$upload_dir = DOCROOT.'/'.Uploads::getDirectory($id_module, $id_plugin);
try {
$fattura = new Plugins\Fatturazione\FatturaElettronica($id_record);
if (!empty($fattura)) {
$disabled = false;
$download = file_exists($upload_dir.'/'.$fattura->getFilename());
} catch (UnexpectedValueException $e) {
$generated = file_exists($upload_dir.'/'.$fattura->getFilename());
} else {
$disabled = true;
$download = false;
$generated = false;
}
// Campi obbligatori per l'anagrafica Azienda
@ -71,7 +68,7 @@ if (!empty($missing)) {
</div>';
}
if ($download) {
if ($generated) {
echo '
<div class="row">
<div class="col-md-6">';
@ -85,17 +82,27 @@ echo '
<input type="hidden" name="op" value="generate">
<button type="submit" class="btn btn-primary btn-lg btn-block'.($disabled ? ' disabled' : null).'" '.($disabled ? ' disabled' : null).'>
<i class="fa fa-file"></i> '.tr('Genera fattura elettronica').'
<i class="fa fa-file"></i> '.tr('Genera').'
</button>
</form>';
if ($download) {
if ($generated) {
echo '
</div>
<div class="col-md-6">
<a href="'.ROOTDIR.'/editor.php?id_module='.$id_module.'&id_plugin='.$id_plugin.'&id_record='.$id_record.'&op=download" class="btn btn-success btn-lg btn-block" target="_blank">
<i class="fa fa-download "></i> '.tr('Scarica fattura elettronica').'
<i class="fa fa-download"></i> '.tr('Scarica').'
</a>
</div>
</div>';
echo '
<hr>
<div class="row">
<div class="col-md-12">
<a href="'.ROOTDIR.'/plugins/fatturazione/view.php?id_record='.$id_record.'" class="btn btn-info btn-lg btn-block" target="_blank">
<i class="fa fa-eye"></i> '.tr('Visualizza').'
</a>
</div>
</div>';

View File

@ -0,0 +1,8 @@
<?php
try {
$fattura = new Plugins\Fatturazione\FatturaElettronica($id_record);
} catch (UnexpectedValueException $e) {
}
$upload_dir = DOCROOT.'/'.Uploads::getDirectory($id_module, $id_plugin);

View File

@ -6,6 +6,8 @@ use FluidXml\FluidXml;
use Respect\Validation\Validator as v;
use Stringy\Stringy as S;
use DateTime;
use DOMDocument;
use XSLTProcessor;
use Uploads;
use Modules;
use Plugins;
@ -94,7 +96,7 @@ class FatturaElettronica
public function isValid()
{
if (empty($this->is_valid)) {
$this->__toString();
$this->toXML();
}
return $this->is_valid;
@ -574,7 +576,7 @@ class FatturaElettronica
// Salvataggio del file
$file = rtrim($directory, '/').'/'.$filename;
$result = directory($directory) && file_put_contents($file, $this->__toString());
$result = directory($directory) && file_put_contents($file, $this->toXML());
// Registrazione come allegato
$this->register($filename);
@ -635,7 +637,7 @@ class FatturaElettronica
*
* @return string
*/
public function __toString()
public function toXML()
{
if (empty($this->xml)) {
$this->is_valid = true;
@ -675,6 +677,33 @@ class FatturaElettronica
return $this->xml;
}
/**
* Restituisce il codice XML formattato della fattura elettronica.
*
* @return string
*/
public function toHTML()
{
// XML
$xml = new DOMDocument();
$xml->loadXML($this->toXML());
// XSL
$xsl = new DOMDocument();
$xsl->load(__DIR__.'/stylesheet-1.2.1.xsl');
// XSLT
$xslt = new XSLTProcessor();
$xslt->importStylesheet($xsl);
return $xslt->transformToXML($xml);
}
public function __toString()
{
return $this->toHTML();
}
/** @var array Elenco di campi dello standard per la formattazione e la validazione */
protected static $validators = [
'IdPaese' => [

File diff suppressed because it is too large Load Diff

View File

@ -0,0 +1,6 @@
<?php
include_once __DIR__.'/../../core.php';
include_once __DIR__.'/init.php';
echo $fattura;

View File

@ -647,3 +647,15 @@ foreach ($movimenti as $movimento) {
}
$dbo->query("UPDATE mg_movimenti SET data = created_at WHERE data = '0000-00-00'");
// File e cartelle deprecate
$files = [
'docs',
'couscous.yml'
];
foreach ($files as $key => $value) {
$files[$key] = realpath(DOCROOT.'/'.$value);
}
delete($files);