maxsoch
7ce6540924
Catégorie/SousCategorie fusionnées en un seul modèle auto-référencé (parent_id), pour permettre une imbrication sans limite de niveaux. Les listings matériels/catégories/destinataires passent en lignes repliées (<details>) avec recherche côté serveur, ce qui corrige le débordement horizontal du tableau tout-en-input et reste utilisable sur de longues listes. Style de l'écran de scan également retravaillé (frontend-design). |
||
|---|---|---|
| .claude | ||
| app | ||
| data | ||
| scripts | ||
| tests | ||
| .env.example | ||
| .gitignore | ||
| CLAUDE.md | ||
| pyproject.toml | ||
| README.md | ||
| requirements-dev.txt | ||
| requirements.txt | ||
Gestion de stock IT
Application web pour le département IT d'une clinique, permettant de gérer le stock de matériel informatique (catégories / sous-catégories / matériels), avec scan de codes-barres et alertes email de stock bas.
Pas de système d'authentification dans l'app : l'accès est censé être restreint par un mécanisme externe (réseau interne, proxy, etc.).
Stack
- Python + FastAPI : serveur web, un seul processus.
- SQLite : base de données fichier (
data/stock.db), aucun serveur à installer. - Jinja2 : pages HTML rendues côté serveur, formulaires classiques (pas de JS de build).
- SQLModel : ORM (combine SQLAlchemy + validation Pydantic).
Tout vit dans ce dossier : pas de service externe requis pour développer et tester en local (les emails d'alerte sont simulés dans la console tant qu'aucun SMTP n'est configuré, voir plus bas).
Démarrer en local
python3 -m venv .venv
source .venv/bin/activate # Windows : .venv\Scripts\activate
pip install -r requirements-dev.txt
cp .env.example .env # optionnel en local, voir ci-dessous
uvicorn app.main:app --reload
L'app est accessible sur http://127.0.0.1:8000. La base SQLite est créée
automatiquement au premier démarrage dans data/stock.db.
Lancer les tests
source .venv/bin/activate
pytest
Lancer le linter
source .venv/bin/activate
ruff check .
Configuration des emails d'alerte
Les alertes de stock bas sont envoyées par email via le relais SMTP interne
de la clinique, configuré par variables d'environnement (voir .env.example) :
SMTP_HOST=...
SMTP_PORT=25
SMTP_USER=...
SMTP_PASSWORD=...
SMTP_FROM=stock-it@clinique.local
Si SMTP_HOST n'est pas renseigné (cas du dev local), les alertes ne sont
pas réellement envoyées : elles sont affichées dans la console du serveur
(--- [EMAIL SIMULÉ] ---). Ça permet de développer et tester tout le flux
d'alerte sans avoir de vrai serveur mail sous la main.
Douchette code-barres
Aucune intégration logicielle particulière : une douchette USB (ou
Bluetooth) émule un clavier, elle "tape" le code puis Entrée. La page
/scan a un simple champ de texte auto-focus dans un formulaire ; Entrée
soumet automatiquement le formulaire.
Structure du projet
app/
main.py point d'entrée FastAPI
config.py lecture des variables d'environnement
database.py connexion SQLite
models.py modèles SQLModel (Categorie, SousCategorie, Materiel, DestinataireAlerte)
email_alerts.py logique d'envoi/simulation des alertes email
templates_engine.py instance Jinja2Templates partagée
routers/ une route FastAPI par ressource (categories, materiels, scan, destinataires)
templates/ pages HTML (Jinja2)
static/ CSS
tests/ tests pytest (client de test FastAPI + base SQLite en mémoire)
data/ base SQLite locale (ignorée par git)