# Installazione database from-scratch

Questa cartella contiene la procedura di **prima installazione** dei database
della piattaforma MyTown su PostgreSQL (16/17), generata e validata su
un'installazione di riferimento.

## Contenuto

| File | Contenuto |
|---|---|
| `10_schema_<db>.sql` | DDL (tabelle, funzioni, viste, FDW) di ciascun database — istantanea di un'installazione di riferimento |
| `11`…`19_migrations_*.sql` | Correzioni e oggetti richiesti dal codice ma assenti nell'istantanea (chat mute, posizione/organizzazione menu, branding, anagrafica clienti, stato fattura elettronica, IVA listino Booking, preset obbligatorio in `add_service`, coda download allegati, segnalazione post bacheca, voce di menu dei form rapportino, aliquota IVA dei prodotti). Idempotenti; `install.sh` applica ciascun file al database indicato nella sua intestazione |
| `20/21/22_seed_<db>.sql` | Dati di catalogo: menu/pagine, moduli e permessi, ruoli, traduzioni, comuni/province, tipologie (IVA, ATECO, CCNL, categorie gare/CEL/certificati, stati cantiere, template documentali, widget) |
| `30_bootstrap_KCS-Portal.sql` | Prima configurazione: utente amministratore, utente di sistema "piattaforma", portale e alias |
| `31_bootstrap_CompanyDB.sql` | **Azienda base** con tutti i servizi (preset) abilitati e il form predefinito del rapportino |
| `32_bootstrap_Documentary.sql` | **Radice del documentale** (cartella `base_folder_id` + scheda metadati predefinita) |
| `install.sh` | Esegue tutto nell'ordine giusto |

> Perché serve l'azienda base: il portale risolve il menu dalla catena
> azienda → servizi (preset) → pagine. Senza almeno un'azienda le chiamate
> partono con `cmp_id = -1`, il menu resta vuoto e alcune pagine vanno in errore.

> Perché serve la radice del documentale: ogni cartella nasce sotto una cartella
> padre e ne eredita il percorso su disco. Senza radice qualunque creazione di
> cartella (allegati, cantieri, dipendenti) termina in errore. `DOC_ROOT` deve
> coincidere con `file_upload_destination_path` di `ws_spring_documentary`.

Database creati: `KCS-Portal`, `CompanyDB`, `bizappointments`, `bk_booking`,
`onlineshop`, `Bakeka`, `DataRepository`, `Documentary`, `payment`
(gli stessi nomi referenziati nelle `config/example` dei microservizi).

## Uso

```bash
export DB_PASSWORD='<password del ruolo applicativo>'
export ADMIN_MAIL='admin@example.com'
export ADMIN_PASSWORD='<password amministratore>'
export PORTAL_URL='https://portale.example.com'
export PORTAL_NAME='MyTown'          # opzionale
export COMPANY_NAME='La Mia Azienda' # opzionale (default: PORTAL_NAME)
export DOC_ROOT='/var/www/allegati'  # opzionale: radice su disco del documentale
sudo -u postgres ./install.sh
```

`install.sh` richiede una connessione superuser per la Fase 1 (ruolo
applicativo `kondor`, database, estensioni `postgres_fdw`/`pgcrypto`, grant);
se `sudo -u postgres psql` non è utilizzabile (pg_hba con `scram-sha-256`
anche per le connessioni locali), impostare `PSQL_SUPER` con una stringa di
connessione valida, es. `PSQL_SUPER="psql -h 127.0.0.1 -U postgres"` e
`PGPASSWORD` del superuser.

## Primo accesso

- Login: `ADMIN_MAIL` / `ADMIN_PASSWORD`.
- Il login è a **due fattori**: il codice OTP viene recapitato dal job
  *Notificatore* dello scheduler (vedi repository
  `kondorcs.schedulelibrary.datasmart`). Se lo scheduler non è ancora attivo,
  il codice si può leggere direttamente dal database:

  ```sql
  SELECT * FROM contact_login_bidtoken_get('<ADMIN_MAIL>');
  ```

## Note sul perimetro

- Gli schemi sono quelli dell'edizione open source: i moduli enterprise della
  piattaforma di origine (helpdesk ticketing, HR, gestione flotte, webmail,
  listini prezzi) non sono inclusi.
- Alcune viste/funzioni "dual-mode" (certificati di pagamento, sopralluoghi,
  fatture) uniscono dati locali a tabelle remote di moduli enterprise: in
  questa edizione quelle tabelle remote sono **stub locali vuoti** (cercare
  `stub locale` nei DDL), quindi le funzioni restano valide e i rami
  enterprise restituiscono zero righe.
- Le `USER MAPPING` dei collegamenti FDW tra i database usano il placeholder
  `__FDW_PASSWORD__`, sostituito da `install.sh` con `DB_PASSWORD`.
- I seed contengono solo dati di catalogo dell'installazione di riferimento
  (nessun dato personale, nessuna credenziale). Le tabelle operative
  (aziende, utenti, fatture, cantieri, conversazioni…) partono vuote.
