Project

Profile

Help

Créer un workflow personnalisé pour les tâches récurrentes » History » Revision 2

Revision 1 (Jan Schulz-Hofen, 07/28/2017 09:13 AM) → Revision 2/12 (Blandine Proust, 09/25/2017 10:31 PM)

# Créer un Create a custom workflow personnalisé pour les tâches récurrentes for recurring tasks 

 Planio est performant pour organiser des [projets ponctuels](https://plan.io/fr/gestion-projet/), mais il est aussi idéal pour les [tâches récurrentes](https://plan.io/fr/gestion-taches/) qui suivent un is not only great for [one-off projects](https://plan.io/project-management/). It really shines when it comes to [recurring tasks](https://plan.io/task-management/) that follow a certain workflow au sein de votre organisation. within your organization. 

 Ce Follow along this guide vous explique comment créer un to create a simple vacation approval workflow simple pour la validation des congés de votre équipe. Vous pourrez ensuite réutiliser ce que vous avez appris pour créer vos propres for your team members - and apply what you've learned to create your own custom workflows. 

 {{>toc}} 

 ## Les bases du Planio workflow dans Planio basics 

 Dans In Planio, chaque demande doit appartenir à un tracker, qui définit le every issue must belong to a tracker which defines its workflow. Observons cela plus en détail : Let's look at this in more detail: 

 ### Trackers 

 Considérons les We'd like to see trackers comme des types de demandes spéciaux. Une demande doit appartenir à un tracker, ni plus ni moins. Quelques exemples de tracker : **Tâche**, **Assistance**, **Bug** ou **Demande de congés** (dans notre cas précis). as special issue types. An issue must belong to exactly one tracker. **Task**, **Support incident**, **Software bug**, or -- you guessed it -- **Vacation request** would be great examples for a tracker. 

 ### Statuts des demandes Issue statuses 

 Les statuts des demandes correspondent aux différents états dans lesquels une demande Issue statuses describe the different states, that an issue in Planio peut se trouver à un moment donné. Par exemple, une demande peut avoir le statut **Ouvert**, **En cours**, **Commentaire** ou **Fermé**. Une demande a un seul statut à la fois. Ce statut can have at any given moment. For instance, an issue can be **Open**, **In progress**, **Waiting for review**, or **Closed**. An issue will always have exactly one status and the status will likely change au fur et à mesure que l’équipe travaille sur la demande. over time as people work on the issue. 

 ### Rôles Roles 

 Chaque utilisateur de Users in Planio possède son propre compte utilisateur et participe au projet en prenant un ou plusieurs rôles : certains utilisateurs peuvent avoir le rôle de have their own user account using which they take part in projects using one or more roles: While some users may take part as *Manager*, d’autres celui de *Membre d’équipe* ou de *Client*, par exemple. Le rôle détermine ce que l’utilisateur peut ou ne peut pas voir dans un projet donné, ainsi que son others may be regular *Staff* or e.g. *Client*. The role defines what a user can and cannot see or do in a given project. It also defines the user's workflow. 

 ### Workflows 

 Un The workflow réunit tous les aspects cités précédemment : il définit les statuts possibles pour chaque combinaison de brings it all together: A workflow defines for every possible combination of tracker et de rôle. Pour toutes les demandes d’un tracker, il détermine quelles sont les modifications de statut autorisées et quelles propriétés de la demande sont visibles et/ou modifiables. and role which issue statuses are available. It defines for all its tracker's issues which status changes are allowed and which issue properties are visible and/or changeable. 

 Et en clair, qu’est-ce que ça veut dire ? Cette partie est probablement la plus complexe (et la plus puissante) de Planio mais ne vous inquiétez pas : nous allons vous guider de A à Z et les workflows n’auront bientôt plus aucun secret pour vous ! Say what!? This is arguably the most complex (and powerful) part of Planio, but don't worry -- we will walk you through it and you will be a workflow expert in no time! 

 ## Partir en congés : aspects techniques Technicalities of going on a vacation 

 Cette section vous plaît ? On s’en doutait. Vous rêvez de partir vous détendre sur une plage déserte à l’autre bout du monde ? Demandez quelques jours de congés et faites vos valises. We knew you would love this section. Dreaming of that deserted beach in the Caribbean? Let's request some vacation days and off we go. 

 Dans beaucoup d’entreprises, les congés doivent être validés par un In many companies, taking a vacation requires approval by a manager. L’employé soumet une demande en indiquant une Employees must submit a request mentioning the start and end date de début et une date de fin de congés, puis le manager valide ou refuse la demande. Une fois la demande validée, elle est considérée comme définitive et les of the requested vacation and managers will approve or disapprove the request. Upon approval, the dates de congés ne peuvent plus être modifiées. En cas de refus, l’employé peut modifier les of that vacation can not be altered, and the vacation request is final. If disapproved, employees can alter their requested dates demandées et renvoyer sa demande pour qu’elle soit validée (enfin, on l’espère). and re-request approval until -- hopefully -- they will be allowed their well-deserved days in the Caribbean. 

 Nous allons maintenant construire ce We will now build this workflow dans in Planio afin d’implémenter une fonction de demande et de validation de jours de congés. Nous allons également découvrir comment visualiser les congés sur le calendrier Planio pour avoir une vue d’ensemble de tous les employés absents à un moment T. allowing for actual vacation requests being made and approved. We will also show you how to visualise them on Planio's calendar, so you can get a great overview on who is on vacation at which point in time. 

 ## Tracker, statuts, rôles et workflow Statuses, Roles, and Workflow 

 Pour mettre en place cette fonction, nous allons créer un To implement this, we will create a **Tracker** appelé *Demande de congés*, trois **Statuts de demandes** intitulés *Ouvert*, *Validé* et *Refusé*, et deux \*Rôles\* : called *Vacation request*, three **Issue statuses** called *Open*, *Approved*, and *Rejected*, and two **Roles**, called *Manager* et *Membre d’équipe*. and *Staff*. 

 Enfin, nous allons les assembler pour former un **workflow** personnalisé. Finally, we will tie all those together using a custom **Workflow** in Planio. 

 ### Créer le Create the tracker 

 Commençons par le commencement. First things first. Let's get down to business: 

   - Allez dans *Votre avatar* -\> Navigate to **Administration** -\> **Trackers**, puis cliquez sur **Nouveau then click on **New tracker**. 
   - Entrez *Demande de congés* dans le champ **Nom**. Enter *Vacation request* as **Name**. 
   - Sélectionnez *Ouvert* dans le champ **Statut par défaut**. Uncheck the **Issues displayed in roadmap** checkbox since we do not want to see vacation days on our project roadmaps. 
   - Décochez la case **Demandes affichées dans la roadmap**, car nous ne voulons pas afficher les jours de congé dans les roadmaps de nos projets. Uncheck all **Standard fields** checkboxes except the ones for **Start date** and **Due date**. We'll actually use those for the start and end of our vacations. 
   - Décochez toutes les cases des **Champs standards**, à l’exception de **Début** et **Échéance**. C’est ici que nous entrerons les dates de début et de fin des congés. 
   - Ne sélectionnez rien dans la liste déroulante **Copier le Do not select anything in the **Copy workflow de**. from** drop down. 
   - Cliquez sur **Créer**. Click **Create**. 

 {{figure(Voilà à quoi devrait ressembler votre tracker.) 
 !creating_a_new_tracker@2x.png! 
 }} ![](creating_a\_new_tracker.png)   
 *Your tracker should look like this.* 

 ### Créer des statuts de demandes Create issue statuses 

 La procédure est similaire, mais légèrement différente pour les trois statuts *Ouvert*, *Validé* et *Refusé*. The steps are similar but slightly different for the three statuses *Open*, *Approved*, and *Rejected*. 

   - Allez dans *Votre avatar* -\> Navigate to **Administration** -\> **Statuts de demandes**. **Issue statuses**. 
   - Vous voyez un statut nommé *Ouvert\_ ? Parfait, vous pouvez passer cette étape. Vous ne voyez pas ce statut ? Cliquez sur **Nouveau statut**, entrez \_Ouvert* dans le champ **Nom** et décochez la case **Ajouter à tous les workflows**, car ce statut est destiné uniquement à notre workflow *Demande de congés*. Ensuite, cliquez sur **Créer**. Do you see a status called *Open*? Great, click on it, and make sure that the **Default value** checkbox is checked. This will make *Open* the default status that's always the first status for a newly created issue. 
   - Créez les deux autres statuts *Validé* et *Refusé* en suivant la même procédure et assurez-vous que la case **Demande fermée** est cochée pour le statut *Validé*. Do not see the status? Simply click on **New status**, enter *Open* in the **Name** field, and check the **Default value** checkbox. Uncheck the **Add to all workflows** checkbox since we only want it for our *Vacation request* workflow. 
   - Click on **Save** or **Create** respectively. 
   - Create the remaining statuses *Approved* and *Rejected* following the same pattern and make sure the *Approved* status has the **Issue closed** checkbox checked. Do not check the **Default value** checkbox for *Approved* and *Rejected*. 

 {{figure(Voilà à quoi devrait ressembler votre statut Validé.) 
 !create_an_issue_status@2x.png! 
 }} ![](create_an_issue_status.png)   
 *This is what your "Approved" status will look like.* 

 ### Créer un rôle Create a role 

 Cette étape devrait être facile : This one should be easy: 

   - Allez dans *Votre avatar* -\> Navigate to **Administration** -\> **Rôles et **Roles and permissions**. 
   - Est-ce que les rôles Do you see the roles *Manager* et *Membre d’équipe* existent déjà ? Parfait. Cette étape est terminée. Il s’agit des deux rôles de base qui ont été créés automatiquement à l’ouverture de votre compte Planio. and *Staff* already? Great. You're done with this step. Those are actually the two basic roles your Planio account came with. 
   - Vous ne voyez pas les rôles ? Créez-les en cliquant sur **Nouveau rôle**. Entrez le **Nom** du rôle et ignorez le reste pour le moment. Assurez-vous simplement que les cases des Do not see the roles? Create them by clicking on **New role**. Enter the role's **Name** and ignore the rest for now, just be sure that the check boxes for permissions **Voir le calendrier**, **Modifier les demandes**, **Voir les demandes** et **Créer des demandes** sont cochées. Réalisez cette étape pour les deux rôles **View calendar**, **Edit issues**, **View issues**, and **Add issues** are checked. Repeat this for both the *Manager* et *Membre d’équipe*. and *Staff* roles. 

 {{figure(Ajouter un rôle) 
 !how_to_add_a_role@2x.png! 
 }} ![](how_to_add_a\_role.png)   
 *Adding a role* 

 ### Définir le Define the workflow 

 Les choses vont commencer à devenir amusantes. Nous allons assembler tous ces maillons pour constituer un workflow. This is the fun part. Here is where it all comes together. 

   - Allez dans *Votre avatar* -\> Navigate to **Administration** -\> **Workflow**. 
   - Sélectionnez le rôle *Membre d’équipe* et votre tracker *Demande de congés*. Select the *Staff* role and your *Vacation request* tracker. 
   - Décochez la case **N’afficher que les statuts utilisés dans ce Uncheck the **Only display statuses that are used by this tracker** et cliquez sur **Modifier**. checkbox and click on **Edit**. 
   - La grille qui s’affiche vous permet de configurer tous les changements de statut autorisés pour un rôle et un tracker donnés. Par exemple, les cases en haut et en bas à gauche du The checkbox matrix that appears lets you configure all allowed status transitions for a given role and tracker. For instance, the *Staff* workflow *Membre d’équipe* doivent être cochées. Cela signifie que les membres ayant le rôle *Membre d’équipe* peuvent créer de **nouvelles demandes** avec le statut *Ouvert* et rouvrir une demande refusée (**statut actuel** *Refusé* \> *Ouvert*.) should have the checkbox at the lower left checked. This means that members having the role *Staff* can set an issue having a **current status** of *Rejected* back to *Open*. 
   - Nous allons maintenant configurer le Now, let's configure the *Staff* workflow *Membre d’équipe* en reproduisant la capture d’écran suivante : according to the following screenshot:   
     {{figure(Workflow pour le rôle Membre d’équipe) 
 !vacation_request_workflow_for_staff@2x.png! 
 }} ![](vacation_request_workflow_for_staff.png)   
     *Workflow for Staff role* 
   - Cliquez sur **Sauvegarder**. Click on **Save**. 
   - Ensuite, sélectionnez le rôle *Manager*, assurez-vous que la case **N’afficher que les statuts utilisés dans ce Next, select *Manager* as a role, make sure the **Only display statuses that are used by this tracker** est décochée et cliquez sur **Modifier**. checkbox is unchecked click on **Edit** again. 
   - Configurez le Configure the *Manager* workflow *Manager* en reproduisant la capture d’écran suivante : according to the following screenshot:   
     {{figure(Workflow pour le rôle Manager) 
 !vacation_request_workflow_for_manager@2x.png! 
 }} ![](vacation_request_workflow_for_manager.png)   
     *Workflow for Manager role* 
   - Cliquez sur **Sauvegarder**. Click on **Save**. 

 Un instant. Revenons sur nos captures d’écran. Nous avons défini les opérations suivantes : Wait, what did we just do? Have a look at the screenshots again. What we defined is: 

   - Les *managers* peuvent valider ou refuser une demande de congés ouverte (statut *Ouvert* \> *Validé* ou *Ouvert* \> *Refusé*) et valider une demande de congés refusée (statut *Refusé* \> *Validé*), si jamais ils changent d’avis. *Managers* can set an open vacation request to *Approved* or *Rejected* and a *Rejected* vacation request to *Approved* (in case they changed their mind).  
   - Un *membre d’équipe* peut uniquement rouvrir une demande de congés refusée (statut *Refusé* \> \_Ouvert), s’il souhaite changer ses *Staff* can only set a *Rejected* vacation request back to *Open*. (This is for when they change their dates et soumettre la demande modifiée. and want to re-request approval.) 

 ### Adapter les Adapt fields permissions sur les champs 

 Nous allons maintenant personnaliser les champs qui seront visibles sur le formulaire de la demande en fonction du statut. Now, let's customize the issue form fields a bit according to the issue status. 

   - Toujours sur l’écran **Workflow**, cliquez sur l’onglet **Permissions sur les champs**. Still on the **Workflow** screen, select the **Fields permissions** tab. 
   - Pour le rôle For *Manager*, mettez tous les champs en *Lecture* sauf le champ **Sujet**. Pour économiser quelques clics, vous pouvez copier une valeur sur toute la rangée en cliquant sur l’icône **»**. set everything to *read-only* except the **Subject**:   
     {{figure(Permissions sur les champs pour le rôle Manager) 
 !fields_permissions_manager@2x.png! 
 }} ![](fields_permissions_manager.png)   
     *Fields permissions for Manager role* 
   - Pour le rôle *Membre d’équipe*, faites de même sauf pour les champs **Début** et **Echéance**, qui doivent être obligatoires : For *Staff*, do the same except for the **Start date** and **Due date** fields:   
     {{figure(Permissions sur les champs pour le rôle Membre d’équipe) 
 !fields_permissions_staff@2x.png! 
 }} ![](fields_permissions_staff.png)   
     Avec cette configuration, seul un *Membre d’équipe* peut définir les *Fields permissions for Staff role*   
     This makes sure only *Staff* can actually set the dates de sa demande de congés et ces for a vacation request and that those dates ne pourront plus être modifiées une fois la demande validée. cannot be changed anymore, once approved. 

 ## Utiliser le workflow en conditions réelles Put it all to work in an actual project 

 Les préparatifs sont terminés ; passons maintenant à la pratique. That's enough of prep work. Let's try it out. 

   - Commencez par créer un nouveau projet Start by creating a new project via **Projets** **Projects** -\> **Nouveau projet**. **New project**. 
   - Donnez un nom à votre projet, par exemple **Congés**. Give your project a name, e.g. **Vacation planning**. 
   - Désactivez tous les **modules** à l’exception de **Suivi des demandes** et **Calendrier**. Disable all modules but **Issue tracking** and **Calendar**. 
   - Sélectionnez uniquement votre Select only your **Vacation request** tracker **Demande de congés** et rien d’autre. and nothing else. 
   - Cliquez sur **Créer**. Click **Create**. 

 Voilà, vous avez terminé. Vos utilisateurs peuvent commencer à utiliser ce projet pour planifier les prochains congés. Pour soumettre une demande de congés, il leur suffit de créer une nouvelle demande. Au moment de créer une *Demande de congés*, les champs **Début** et **Echéance** devront être remplis, tous les autres seront invisibles. That's it, you're done. Your users can now use this project for your new vacation request planning workflow. In order to submit a vacation request, all they'd have to do is create a new issue. Selecting a **start date** and a **due date** will be required when creating *vacation request* issues and all other useless fields will be hidden. 

 {{figure(Formulaire simplifié pour la saisie des demandes de congés) 
 !new_issue_form@2x.png! 
 }} ![](new_issue_form.png)   
 *Stripped down issue form for vacation requests* 

 Si vous voulez tester ce workflow par vous-même, nous vous recommandons de créer deux utilisateurs (*Votre avatar* \> **Administration** -\> **Utilisateurs**) sans droits administrateurs et de les ajouter comme *Membre d’équipe* et In order to try it out for yourself and play around with it, we recommend you create two users that have no administrator privileges and add the as *Staff* and *Manager* à votre projet. to your project respectively. 

 Si vous faites des tests en tant qu’administrateur et que vous modifiez une demande, vous pourrez toujours sélectionner un statut dans une liste avec tous les statuts. Ne vous étonnez pas : c’est (If you try it out as an administrator, don't be alarmed by the fact that you can always choose from all statuses when updating an issue. That's normal pour les administrateurs. Les utilisateurs non administrateurs ne verront que les statuts définis dans leur workflow. if you're an admin. Regular users will only see the statuses as defined by their workflow.) 

 ### Bonus : la vue Calendrier Bonus: The calendar view 

 Vous vous demandez peut-être pourquoi nous avons activé le What's up with the **Calendar** module **Calendrier** dans nos rôles et notre projet. Eh bien, après avoir ajouté quelques demandes de congés, allez dans l’onglet **Calendrier** de votre projet Planio. Vous y verrez le calendrier mensuel de toutes les demandes de congés qui ont été saisies. we've enabled in the roles and your project, you ask yourself? Well, after adding a couple of vacation requests, check out the **Calendar** tab in your project. The Planio calendar will give you a nice monthly overview of all vacation requests which have been tracked. 

 {{figure(Vue du calendrier des congés dans Planio) 
 !vacation_calendar@2x.png! 
 }} ![](vacation_calendar.png)   
 *Vacation calendar view in Planio* 

 En utilisant une [requête personnalisée](http://plan.io/blog/post/25072622222/trackers-viewing-and-grouping), vous pouvez même créer une vue calendrier qui affiche uniquement les demandes validées. Ou créer une requête pour que les By using a [custom query](http://plan.io/blog/post/25072622222/trackers-viewing-and-grouping), you can even create a calendar view that displays only approved vacation requests. Or create a query for your managers ne voient que les demandes de congés à valider (c’est-à-dire ayant le statut *Ouvert*). that shows only *Open* requests that have to be approved still.