fix #35 |
2 months ago | |
---|---|---|
betg | 2 months ago | |
fixtures | 6 years ago | |
requirements | 2 years ago | |
scripts | 6 years ago | |
var/log | 6 years ago | |
.editorconfig | 2 years ago | |
.gitignore | 6 years ago | |
CHANGELOG.md | 6 years ago | |
CONTRIBUTORS.txt | 6 years ago | |
LICENSE | 6 years ago | |
Makefile | 2 years ago | |
README.md | 6 years ago | |
config.env.example | 2 years ago | |
manage.py | 2 years ago | |
pyproject.toml | 2 years ago | |
remig.sh | 6 years ago | |
requirements.txt | 6 years ago | |
setup.cfg | 2 years ago |
README.md
BETG
Bien Être au Travail à Grenay
Installation
Pré-requis
Sur un système basé sur Debian - (au moins sur la version 8 - Jessie) les paquets suivants sont nécessaires:
- virtualenv
- python3-psycopg2 (en option, dans le cas d'une base de donnée PostgreSQL)
Étape par étape
Voila les étapes à suivre:
-
récupérer les sources de BETG et aller dans le dossier
betg
:git clone https://forge.cliss21.org/cliss21/betg.git
cd betg
-
configurer l'application en ajustant les variables d'environnement en copiant le fichier
config.env.example
enconfig.env
. Editer ce fichier pour l'ajuster à l'environnement d'éxecution (base de donnée, connexion SMTP). La version de base de config.env.example décrit une installation en production et exige une configuration minimale (base de donnée notamment), en basculant la configuration en développement (avecDJANGO_SETTINGS_MODULE
), BETG démarre en créant automatiquement une base de donnée SQLite3.Note: si vous voulez court circuiter ce fichier de configuration et n'utiliser que des variable d'environnement, il faut alors positionner la variable d'environnement
DJANGO_READ_CONFIG_FILE
àfalse
. -
créer l'environnement de base:
make init
-
Commandes utiles pour le développement:
make serve
# lance le serveur de dev.make help
# affiche toutes les cible du Makefilemake test
# joue le jeu de test sur l'applicationmake lint
# verifie le code avecflake8
. venv/bin/activate
# pour activer l'environnement virtuel
Configuration
Evenements et réservations
...Éléments variables par évenement...
[ouverture ] [fermeture ] [alerte ou annulation] [évenement]
[reservation] [reservation] [de l'évenement si ] |
[par défaut:] [par défaut:] [nb de participants ] |
[jour créa ] [limite créa] [insuffisants ] |
[évenement ] [évenement ] | |
| | | |
======================|=================||========(temps -> )=============|=>
| ||<-ALERT_NB_J_AV_EVT_PART_INSUF->|
| | (par def: 8j) |
| | |
|<-TPS_REFLEXION->|<----VAL_AUTO_NB_J_AV_EVT------->|
| (par def: 7j) | (par def: 9j)
| |
[limite création] [validation ]
[évenement et ] [automatique ]
[fermeture ] [de réservation]
[réservations ] [si non réponse]
[par defaut: 16j]
...Éléments communs à toute l'application...
-
VAL_AUTO_NB_J_AV_EVT
: nb de jour avant l'évenement où une réservation qui n'a été ni refusée ni acceptée est acceptée automatiquement -
TPS_REFLEXION
: empêcher les réservations nb de jour avant la validation automatique pour laisser un temps de réflexions aux chefs de service -
TPS_REFLEXION + VAL_AUTO_NB_J_AV_EVT
: represente donc le nb de jours minimaux avant l'évenement pour pouvoir poser une réservation, c'est aussi la limite pour créer un évenement (créer un évenement où personne ne peut réserver n'a pas de sens) -
ALERT_NB_J_AV_EVT_PART_INSUF
: nb de jour avant l'évenement où on vérifie qu'il y a assez de participants pour l'évenement -
si l'évenement n'a pas l'option "annulation auto" alors seul l'organisateur de l'évenement sera prévenu et l'évenement n'est pas annulé, sinon on annule l'évenement et on prévient tout le monde
-
le nombre de participants minimal est modifiable par évenement, par défaut c'est la moitié du nombre de place disponible + 1, c'est à dire:
pour 10 places disponible, la limite par défaut est à 6 (10/2 + 1) donc l'évenement sera annulé s'il y a 5 participants ou moins
pour 9 places disponible, la limite par défaut est à 5 ( 9/2 + 1) donc l'évenement sera annulé s'il y a 4 participants ou moins
PCENT_PART_EVT_MIN
: pourcentage a appliquer sur le nombre de place disponibles pour déterminer le nombre de place minimal pour que l'évenement ne soit pas annulé automatiquement. Par défaut, c'est la moitié des places diponibles soit 50%.
Variante (non implémentée):
-
la moulinette "alerte/annulation/confirmation" passerait une premiere fois a la date de fermeture des resa:
-
si on sait dire qu'il n'y a pas assez d'inscrit -> alerte ou annulation selon l'option "annulation auto" de l'evenement et positionnement du drapeau
verif_auto_faite
-
de même s'il y a assez d'inscrits avec le statut "accepté" -> confirmation de l'evenement et validation du drapeau
verif_auto_faite
-
par contre s'il y a assez d'inscrits mais pas assez avec le statut "accepté" (i.e. "en attente") alors on ne fait rien.
-
la moulinette "alerte/annulation/confirmation" passerait une 2eme fois juste après la validation automatique ssi le drapeau
verif_auto_faite
n'est pas positionné. Dans ce cas la il n'y a plus de réservations avec le statut "en attente" et on peut donc trancher: annuler/confirmer (ou simplement alerter).
Cette variante permet de s'affranchir de ALERT_NB_J_AV_EVT_PART_INSUF
(puisqu'on
s'aligne sur VAL_AUTO_NB_J_AV_EVT
et de prévenir le plus tôt possible.
Inconvénient: si l'évenement est annulé par la suite, la confirmation a déjà été envoyée
Structure
Vue d'ensemble
Voila quelques détails sur la structure de dossiers de l'application:
├── CHANGELOG.md
├── CONTRIBUTORS.txt
├── LICENSE
├── Makefile
├── manage.py
├── README.md
├── requirements.txt
├── local
│ ├── static
│ └── templates
├── requirements
│ ├── base.txt
│ ├── development.txt
│ └── production.txt
├── var
│ ├── cache
│ ├── media
│ └── static
└── betg
├── __init__.py
├── apps
│ └── __init__.py
├── settings
│ ├── __init__.py
│ ├── base.py
│ ├── development.py
│ └── production.py
├── static
│ ├── css
│ └── js
├── templates
│ ├── 404.html
│ ├── 500.html
│ └── base.html
├── urls.py
└── wsgi.py
Tout les fichiers de l'application - c'est à dire le code django ainsi que les
settings
, templates
et static
sont dans le sous dossier betg/
.
Cela devrait permettre de distribuer l'application sous forme d'un paquet Python
et de faire une installation globale au système.
Deux environnements sont définits (au niveau des requirements
et des settings
)
-
development
: pour le développement local de l'application et les tests. Utilise une base SQLite3 et active le modedebug
par défaut ainsi que des outils commedjango-debug-toolbar
. -
production
: pour la production: vérifie la configuration (notamment qu'il y a bien une base de donnée configurée).
Changements locaux
Vous pouvez remplacer et étendre les static
et les templates
localement.
Ça peut être utile s'il faut modifier un logo pour une instance donnée.
Pour cela, ajoutez juste vos fichiers dans les dossiers local/static/
et dans
local/templates
. le dossier local/
est volontairement ignoré par git dans
ce but.
Concernant les static
, n'oubliez pas de les re-collecter (avec make static
ou make update
).
Contenu variable
Tout le contenu variable - c'est à dire les téléversement de média par les
utilisateurs, les static
collectés - est stocké dans le dossier var/
.
Ce dossier est aussi ignoré par git étant donné qu'il est spécifique à chaque
installation.
Configuration du serveur web
En conséquence, le serveur web doit être configuré pour service les dossiers sur les chemins suivants:
- dossier
var/media
sur le chemin/media/
- dossier
var/static
sur le chemin/static/
License
BETG est developpé par Cliss XXI sous license AGPLv3+.
BETG is developed by Cliss XXI and licensed under the AGPLv3+.