# Gestion des bénévoles - Comité des fêtes de Beaupont
## Présentation du projet
L'association organise régulièrement des événements et projets mobilisant des bénévoles, mais sa coordination interne est rendue difficile par l'usage d'outils dispersés, et non communicants.
La création d'une plateforme web unique vise donc à centraliser et simplifier la gestion des utilisateurs, des rôles, des événements, des tâches et de la communication. Elle vise à améliorer la collaboration entre tous les bénévoles de l'association.
## Objectifs de l’application
L’application a pour objectifs principaux de :
- Gérer les utilisateurs et leurs rôles au sein de l’association.
- Organiser et planifier les événements et les tâches associées.
- Permettre aux bénévoles de s’inscrire en ligne aux événements et aux tâches.
- Offrir aux responsables un tableau de bord pour suivre la participation et les besoins en ressources humaines.
- Centraliser les informations et la communication autour des projets associatifs.
## Initialisation du projet
### 1. Configuration du fichier `.env` principal
1. Créez un fichier `.env` à la racine du projet.
2. Copiez le contenu du fichier `.env.example` dans le fichier `.env`.
3. Renseignez les variables suivantes :
| Variable | Description |
| --------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `BACKEND_GIT_REPO` | URL HTTPS du dépôt backend sans le préfixe `https://`
(ex : `gitlab.com/user/repo-backend.git`) |
| `FRONTEND_GIT_REPO` | URL HTTPS du dépôt frontend sans le préfixe `https://` |
| `BACKEND_GIT_BRANCH` | Branche de votre dépôt backend à utiliser (ex : `main`, `dev`) |
| `FRONTEND_GIT_BRANCH` | Branche de votre dépôt frontend à utiliser |
| `GIT_TOKEN` | Token GitLab à générer depuis *Préférences → User settings → Personal access tokens*
Permissions requises :
- `read_repository` (obligatoire)
- `write_repository` (optionnel, uniquement en développement) |
| `DB_CONNECTION` | Type de base de données utilisée (ex : `mysql`, `mariadb`) |
| `DB_HOST` | Adresse du serveur de base de données (ex : `localhost`, `db`) |
| `DB_PORT` | Port de la base de données (ex : `3306` pour MySQL/MariaDB) |
| `DB_DATABASE` | Nom de la base de données |
| `DB_USERNAME` | Nom d’utilisateur de la base de données |
| `DB_PASSWORD` | Mot de passe de l’utilisateur de la base de données |
| `DB_ROOT_PASSWORD` | Mot de passe du compte root de la base de données |
| `FORCE_CLONE` | Mettre à `true` pour forcer le clonage du dépôt backend même si la branche configurée diffère de la branche actuelle. |
| `DEV` | Mettre `1` en environnement de développement, laisser vide sinon. |
| `VITE_API_URL` | URL du frontend hébergé et exposé par le conteneur Nginx (par défaut sur le port 80) |
### 2. Configuration du fichier `.env` php
Répétez la même opération pour le fichier `docker/php/.env` en copiant depuis `docker/php/.env.example`.
De plus, un utilisateur administrateur est automatiquement créé avec les informations suivantes :
- **Prénom :** `admin`
- **Nom :** `admin`
- **Adresse e-mail :** `admin@mail.com`
- **Mot de passe :** `admin`
- **Numéro de téléphone :** `0909090909`
> Il est bien sûr possible de modifier ces valeurs dans le fichier ``docker/php/.env`` avant le premier lancement du seeder, en utilisant les variables : ``ADMIN_NAME``, ``ADMIN_LASTNAME``, ``ADMIN_MAIL``, ``ADMIN_PASSWORD``et ``ADMIN_PHONE_NUMBER``
## Installation et lancement
Une fois la configuration terminée :
1. Ouvrez un terminal.
2. Placez-vous à la racine du projet.
3. Exécutez les commandes suivantes dans l'ordre :
```bash
docker compose down -v
```
> Arrête et supprime les conteneurs existants ainsi que les volumes associés.
> Cette étape permet de repartir sur une base propre.
```bash
compose up --build -d
```
> Reconstruit les images Docker et démarre l’ensemble des services en arrière-plan.
## Note importante
> ⚠️ Si vous êtes sous **Windows**, assurez-vous que tous les fichiers `.sh` utilisent des fins de ligne **LF** et non **CRLF**, sous peine d’erreurs lors de l’exécution des scripts.