# newfarahgroupe

Plateforme SaaS multi-établissement pour la gestion hospitalière, en
remplacement de `MyFARAH_Web` (PHP procédural legacy). PHP 8.1+ sans
framework, une base de données MySQL par établissement.

## Deux espaces

- **`admin.newfarah`** (`public/admin/`) — back-office plateforme : super-admins,
  CRUD établissements (avec provisioning automatique d'une base + d'un compte
  MySQL restreint par établissement), catalogue de modules, activation par
  établissement.
- **`app.newfarah`** (`public/app/`) — l'application métier elle-même
  (multi-tenant, résolue par sous-domaine) : patients, rendez-vous, médecins,
  facturation, laboratoire, hospitalisation, ententes/assurances, imagerie,
  CMS, buanderie, utilisateurs/rôles.

## Architecture en bref

```
public/
  admin/index.php   # front controller admin.newfarah
  app/index.php     # front controller app.newfarah
  assets/           # CSS/JS partagés par les deux espaces (voir DEPLOYMENT.md)
  router-dev.php    # routeur pour `php -S` en LOCAL UNIQUEMENT (voir plus bas)
src/
  Core/             # Database, Auth, Http, Security, Support, View, Storage,
                     # Authorization, Notification, Hl7 — briques réutilisées
                     # par tous les modules
  Admin/             # Controllers/Repositories/Services de admin.newfarah
  App/{Module}/      # Controllers/Repositories/Services de chaque module métier
  Migration/         # Migrateurs depuis la base legacy my_farah (voir MIGRATION.md)
resources/{admin,app}/views/   # Vues PHP (pas de moteur de template externe)
database/
  admin/migrations/           # Schéma de la base admin centrale
  tenant_template/migrations/ # Schéma cloné pour chaque nouvel établissement
  migrate-legacy/             # Outils et données pour MIGRATION.md
tests/{Unit,Feature}/         # PHPUnit, contre une vraie base MySQL (pas de mocks)
```

Pattern systématique par module : `Repository` (SQL) → `Service` (règles
métier, validation, transactions) → `Controller` (HTTP) → vue PHP.

## Démarrer en local

```bash
composer install
cp .env.example .env   # renseigner APP_ENCRYPTION_KEY, ADMIN_DB_*, etc.

# Base admin
php bin/migrate.php admin

# Une base tenant (un établissement réel se crée normalement depuis
# admin.newfarah, qui fait ça automatiquement — ceci est juste pour un essai manuel)
php bin/migrate.php tenant --host=127.0.0.1 --database=newfarah_tenant_demo --username=root

# Servir les deux espaces avec un seul serveur de dev PHP
php -S 127.0.0.1:8000 -t public public/router-dev.php
```

`public/router-dev.php` n'existe que pour `php -S` en local : il choisit
`public/admin/index.php` ou `public/app/index.php` selon que le Host commence
par `admin.` ou non, et laisse passer les fichiers statiques de `public/assets/`
tels quels. **Il n'est jamais utilisé en production** — voir `DEPLOYMENT.md`
pour la configuration de vhost réelle (ce routeur reproduit simplement, en
local, ce qu'un vrai vhost ferait).

## Tests

```bash
vendor/bin/phpunit
```

Tous les tests `Feature` tournent contre de vraies bases MySQL locales,
jamais de mocks : `newfarah_admin_test`, `newfarah_tenant_test` (avec le
schéma `tenant_template` appliqué) et `newfarah_legacy_test` (schéma
synthétique, voir `database/migrate-legacy/legacy_fixture_schema.sql`). Ce
sont des fixtures **permanentes** : ne jamais les supprimer, seules leurs
lignes sont nettoyées par les tests eux-mêmes.

## Assets front

JS vanilla + librairies ciblées, vendorisées (pas de CDN, pas de build step) :
Alpine.js, Chart.js, Toastify, Lucide — voir `public/assets/vendor/README.md`.
`bin/build-assets.php` régénère `public/assets/js/{toast,charts}.js` en
bundlant Toastify/Chart.js avec un wrapper qui garde l'API déjà utilisée par
les vues (`NewFarahToast.show()`, `NewFarahCharts.bar()`).

## Pour aller plus loin

- `MIGRATION.md` — état réel de la migration des données depuis `my_farah`
  (ce qui a été migré, ce qui est bloqué et pourquoi).
- `DEPLOYMENT.md` — configuration vhost de production, variables d'environnement,
  sauvegardes.