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:

1. récupérer les sources de BETG et aller dans le dossier betg:

   • git clone https://forge.cliss21.org/cliss21/betg.git
   • cd betg

2. configurer l'application en ajustant les variables d'environnement en copiant le fichier config.env.example en config.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 (avec DJANGO_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.

3. créer l'environnement de base:

   • make init

4. Commandes utiles pour le développement:

   • make serve # lance le serveur de dev.
   • make help # affiche toutes les cible du Makefile
   • make test # joue le jeu de test sur l'application
   • make lint # verifie le code avec flake8
   • . 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 mode debug par défaut ainsi que des outils comme django-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+.