M2 — Gestion de projet Redmine

Menu : Projets → Nouveau projet

1. Renseigner les champs Nom et Identifiant — l’identifiant est généré automatiquement à partir du nom, vérifier qu’il correspond à gestion-sinistres

2. Dans la section Modules, cocher : Suivi des demandes, Wiki, Documents, Suivi du temps, Fichiers

3. Sauvegarder

Pour le sous-projet : répéter l’opération, puis dans le champ Projet parent sélectionner Gestion des sinistres.

Vérifier dans la liste des projets que gestion-sinistres-batch apparaît en retrait sous gestion-sinistres.

Menu : Projet gestion-sinistres → Paramètres → onglet Membres → Nouveau membre

1. Sélectionner l’utilisateur dans la liste déroulante

2. Sélectionner le rôle correspondant

3. Cliquer Ajouter — répéter pour les 3 comptes

Vérification par compte :

Menu : Projet → Paramètres → onglet Versions → Nouvelle version

Pour chaque version :

1. Saisir le nom (Sprint 1, Sprint 2)

2. Définir la date d’échéance

3. Statut : Ouvert

4. Sauvegarder

Vérifier via Menu : Projet → Roadmap — les 2 versions doivent apparaître avec leur date et le compteur de demandes (0 pour l’instant).

Voie A — interface web

Menu : Projet → Nouveau ticket

Pour chaque demande, renseigner dans l’ordre : Tracker, Sujet, Priorité, Assigné à, Version cible.

Voie B — import CSV

Menu : Projet → Suivi des demandes → Importer → téléverser demandes-import.csv

Mapper les colonnes :

Lancer l’import — Redmine affiche un récapitulatif : 6 demandes importées, 0 erreur.

Voie C — API REST

Correspondance des identifiants (vérifier dans votre instance) :

Récupérer ID_DEV_MARTIN et les ID_SPRINT1 / ID_SPRINT2 depuis les appels de contrôle indiqués dans l’exercice, puis créer les 6 demandes en adaptant les paramètres.

Vérification commune : Menu Projet → Suivi des demandes → appliquer les filtres suivants :

• Filtre Version = Sprint 1 → doit retourner 4 demandes

• Filtre Tracker = Anomalie → doit retourner 3 demandes

• Filtre Priorité = Urgente → doit retourner 2 demandes

Menu : Projet → Wiki → Modifier (page Accueil générée automatiquement)

Contenu de la page Accueil (exemple) :

# Formation Redmine

Bienvenue sur le wiki du projet.

- [[Procedure-Incident|Procédure de gestion des incidents]]
- [[Contacts|Annuaire des interlocuteurs]]

Contenu de la page Procedure-Incident :

# Procédure de qualification d'une anomalie

## Étape 1 — Réception
Vérifier la complétude du signalement : environnement, reproductibilité, impact.

## Étape 2 — Qualification
Affecter un tracker, une priorité et une version cible.

## Étape 3 — Assignation
Affecter à un développeur et passer le statut en "En cours".

Contenu de la page Contacts :

| Nom | Rôle | Email |
|---|---|---|
| Dupont | Chef de projet | cda.dupont@example.com |
| Martin | Développeur | dev.martin@example.com |
| Durand | Client | client.durand@example.com |

Vérifier que le lien [[Procedure-Incident]] depuis la page Accueil est cliquable et navigue vers la bonne page.

Voie A — interface

Menu Projet → Suivi du temps → Nouvelle entrée de temps

Pour chaque entrée : sélectionner la demande, saisir la durée (format 2 ou 2.5), choisir l’activité, ajouter un commentaire optionnel.

Voie B — API REST

Réponse attendue de enumerations/time_entry_activities.json (ids probables selon configuration M1 EX-07) :

Les 3 entrées à créer :

# 2h Développement sur "Erreur 500"
curl -X POST `
     -H "X-Redmine-API-Key: VOTRE_CLE_API" `
     -H "Content-Type: application/json" `
     -d "{\"time_entry\": {\"issue_id\": ID_ERREUR500, \"hours\": 2, \"activity_id\": 1, \"comments\": \"Correction du module facturation\"}}" `
     http://localhost:3000/time_entries.json

# 0.5h Support sur "Réinitialisation MDP"
curl -X POST `
     -H "X-Redmine-API-Key: VOTRE_CLE_API" `
     -H "Content-Type: application/json" `
     -d "{\"time_entry\": {\"issue_id\": ID_MDP, \"hours\": 0.5, \"activity_id\": 5, \"comments\": \"Réinitialisation effectuée\"}}" `
     http://localhost:3000/time_entries.json

# 1h Documentation sur "MAJ documentation API"
curl -X POST `
     -H "X-Redmine-API-Key: VOTRE_CLE_API" `
     -H "Content-Type: application/json" `
     -d "{\"time_entry\": {\"issue_id\": ID_DOC, \"hours\": 1, \"activity_id\": 4, \"comments\": \"Mise à jour endpoints REST\"}}" `
     http://localhost:3000/time_entries.json

Résultats attendus après filtrage :

Résultat attendu de la consultation API (time_entries.json?project_id=gestion-sinistres) :

{
  "time_entries": [
    {"id": 1, "hours": 2.0, "activity": {"name": "Développement"}, "issue": {"id": ID_ERREUR500}},
    {"id": 2, "hours": 0.5, "activity": {"name": "Support / Assistance"}, "issue": {"id": ID_MDP}},
    {"id": 3, "hours": 1.0, "activity": {"name": "Documentation"}, "issue": {"id": ID_DOC}}
  ],
  "total_count": 3
}

Menu : Projet → Suivi des demandes → section Filtres → Ajouter un filtre

Anomalies urgentes Sprint 1 :

• Tracker → est → Anomalie

• Priorité → est → Urgente

• Version → est → Sprint 1

• Statut → n’est pas → Fermé

Cliquer Appliquer, puis Sauvegarder → saisir le nom → cocher Public → Sauvegarder.

Vérification : se connecter avec dev.martin → Projet → Suivi des demandes → le filtre public doit apparaître dans la liste déroulante des requêtes sauvegardées.

Passage en Résolu : se connecter avec dev.martin → ouvrir la demande → modifier le statut → Sauvegarder.

Passage en Fermé : se connecter avec cda.dupont → ouvrir la demande résolue → modifier le statut → Sauvegarder.

Lecture de la Roadmap :

• La barre de progression = (demandes fermées / total demandes de la version) × 100

• Avec 1 demande fermée sur 4 du Sprint 1 → 25%

• Les demandes encore ouvertes sont listées sous la barre

Lecture du Gantt :

• Chaque demande apparaît comme une barre horizontale positionnée entre sa date de création et son échéance de version

• Le Sprint 2 apparaît si ses demandes ont une date d’échéance définie

Réponse attendue à l’étape 2 (création version) :

{
  "version": {
    "id": 3,
    "project": {"id": 1, "name": "Gestion des sinistres"},
    "name": "Sprint 3",
    "status": "open",
    "due_date": "2026-07-31"
  }
}

L’id retourné (ici 3) est à utiliser aux étapes 4 et 5.

Étape 4 — remplacer ID_SPRINT3 par 3 et ID_DEMANDE par l’id d’une demande existante :

curl -X PUT `
     -H "X-Redmine-API-Key: VOTRE_CLE_API" `
     -H "Content-Type: application/json" `
     -d "{\"issue\": {\"fixed_version_id\": 3}}" `
     http://localhost:3000/issues/5.json

Étape 5 — récupérer l’id du Sprint 1 via l’étape 3, puis fermer :

curl -X PUT `
     -H "X-Redmine-API-Key: VOTRE_CLE_API" `
     -H "Content-Type: application/json" `
     -d "{\"version\": {\"status\": \"closed\"}}" `
     http://localhost:3000/versions/1.json

Vérification : Menu Projet → Paramètres → Versions — le Sprint 1 apparaît en statut “Fermé” et n’accepte plus de nouvelles demandes.

Erreurs fréquentes :

• 422 sur la fermeture de version → des demandes ouvertes sont encore affectées à cette version

• 404 sur /versions/ID → l’id est incorrect, vérifier via versions.json