1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 Définition de workflow |
|
4 ====================== |
|
5 |
|
6 Avant-propos |
|
7 ------------ |
|
8 |
|
9 Un worflow décrit comment les entités vont être utilisés à travers différents états. Nous avons donc pour un workflow donné un ensemble d'états, un "graphe de transition" c'est-à-dire la liste des transitions possibles d'un état à un autre. |
|
10 |
|
11 Nous allons définir ici un simple workflow pour l'exemple du blog avec seulement deux états: `en attente` et `publié`. Il est nécessaire d'avoir préalablement créé une application simple *CubicWeb* en dix minutes (voir :ref:`BlogFiveMinutes`). |
|
12 |
|
13 Mise en place du workflow |
|
14 ------------------------- |
|
15 |
|
16 Nous allons créer un workflow pour contrôler la qualité des BlogEntry soumis à l'instance. Lorsque un BlogEntry est créé par un utilisateur, son état doit être `en attente`. Pour être visible par tous, il doit être ensuite mis à l'état `publié`. Pour le changement d'état d'`en attente` à `publié`, nous avons besoin d'une transition que nous appellerons `approuve_blogentry`. |
|
17 |
|
18 Un état BlogEntry ne doit pas pouvoir être modifiable par les utilisateurs. Nous allons donc créé un groupe de modération `moderateurs` et ce groupe aura les permissions idoines pour publier un BlogEntry. |
|
19 |
|
20 Il existe deux manières de créer un workflow: depuis l'interface utilisateur ou en le définissant dans le fichier ``migration/postcreate.py``. |
|
21 Ce script est exécuté à chaque lancement de la commande ``cubicweb-ctl db-init``. |
|
22 Nous encourageons vivement la création dans ``migration/postcreate.py`` que nous allons vous montrer ici. Lire `Sous le capot`_ pour en comprendre les raisons. |
|
23 |
|
24 L'état d'une entité est sauvegardé par l'attribut `in_state` qui peut être ajouté à votre schéma d'entité par deux façons: |
|
25 |
|
26 * héritage direct en utilisant la classe `cubicweb.schema.WorkflowableEntityType` |
|
27 * par délégation en utilisant `cubicweb.schema.make_worflowable` (utilisable comme un décorateur également) |
|
28 |
|
29 Pour notre exemple de BlogEntry, nous devons avoir: |
|
30 |
|
31 .. sourcecode:: python |
|
32 |
|
33 from cubicweb.schema import WorkflowableEntityType |
|
34 |
|
35 class BlogEntry(EntityType, WorkflowableEntityType): |
|
36 ... |
|
37 |
|
38 |
|
39 Création des états, transitions et les permissions de groupe |
|
40 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
41 |
|
42 Le script ``postcreate.py`` est exécuté dans un environnement spécial où plusieurs primitives *CubicWeb* peuvent être utilsées. |
|
43 Elles sont toutes définies dans ``class ServerMigrationHelper``. |
|
44 Nous allons maintenant voir dans le prochain example celles utilisées pour créer un workflow. |
|
45 |
|
46 Pour définir notre workflow pour BlogDemo, veuillez ajouter les lignes suivantes au script ``migration/postcreate.py``: |
|
47 |
|
48 .. sourcecode:: python |
|
49 |
|
50 _ = unicode |
|
51 |
|
52 moderators = add_entity('CWGroup', name=u"modérateurs") |
|
53 |
|
54 Cela va ajouter le groupe utilisateur `moderators`. |
|
55 |
|
56 .. sourcecode:: python |
|
57 |
|
58 wf = add_workflow(u'une description succincte de votre workflow', 'BlogEntry') |
|
59 |
|
60 Ceci va premièrement instancier un nouvel objet workflow avec une description sommaire mais pertinente et le type d'entité concerné (un tuple pour être utilisé pour des valeurs multiples). |
|
61 |
|
62 .. sourcecode:: python |
|
63 |
|
64 submitted = wf.add_state(_('submitted'), initial=True) |
|
65 published = wf.add_state(_('published')) |
|
66 |
|
67 ``add_state`` attend comme premier argument le nom de l'état que vous voulez créer et un argument optionnel pour signifier si c'est l'état initial supposé pour ce type d'entité. |
|
68 |
|
69 .. sourcecode:: python |
|
70 |
|
71 wf.add_transition(_('approuve_blogentry'), (submitted,), published, ('moderators', 'managers'),) |
|
72 |
|
73 ``add_transition`` attend: |
|
74 |
|
75 * comme premier argument le nom de la transition |
|
76 * ensuite la liste des états pour lesquels les transitions peuvent être tirées, |
|
77 * l'état attendu en fin de transition, |
|
78 * et les permissions |
|
79 (c'est-à-dire la liste des goupes utilisateurs qui peuvnet appliquer la transition; l'utilisateur devant appartenir à l'un des groupes listés pour être autoriser à exécuter l'action). |
|
80 |
|
81 .. sourcecode:: python |
|
82 |
|
83 |
|
84 checkpoint() |
|
85 |
|
86 .. note:: |
|
87 Dans le script de création d'un workflow, penser à mettre `_()` autour des noms d'états et de transitions pour que ceux si soient pris en compte par les scripts de gestion des catalogues i18n. |
|
88 |
|
89 En complément de condition sur des groupes utilisateur dont l'utilisateur doit appartenir à l'in d'entre eux, vous pouvez utiliser une RQL condition. |
|
90 Dans ce cas, l'utilisateur peut seulement exécuter une action si les deux conditions sont satisfaites. |
|
91 |
|
92 Pour la condition RQL sur une transition, on peut y mettre les substitutions suivantes : |
|
93 |
|
94 * `%(eid)s`, eid de l'objet |
|
95 * `%(ueid)s`, eid de l'utilisateur qui fait la requête |
|
96 * `%(seid)s`, eid de l'état courant de l'objet |
|
97 |
|
98 .. image:: ../../images/03-transitions-view.en.png |
|
99 |
|
100 Vous pouvez remarqué que dans la boîte d'action d'un BlogEntry, l'état est maintenant listé ainsi que les possibles transitions définis pour l'état en cours dans le workflow. Les transitions ne sont seulement affichées pour les utilisateurs ayant les bonnes permissions. |
|
101 Dans notre exemple, la transition `approuve_blogentry` sera seulement affichée pour les utilisateurs appartenant au groupe `moderators` or `managers`. |
|
102 |
|
103 |
|
104 Sous le capot |
|
105 ~~~~~~~~~~~~~ |
|
106 |
|
107 Un workflow est une collection d'entités de type `State`` et ``Transition`` qui sont des types d'entités standards de *CubicWeb*. |
|
108 |
|
109 Par exemple, les lignes précédentes: |
|
110 |
|
111 .. sourcecode:: python |
|
112 |
|
113 submitted = wf.add_state(_('en attente'), initial=True) |
|
114 published = wf.add_state(_('publié')) |
|
115 |
|
116 vont créé deux entités de type ``State``, l'une avec le nom 'submitted' et l'autre avec le nom 'published'. Tandis que: |
|
117 |
|
118 .. sourcecode:: python |
|
119 |
|
120 wf.add_transition(_('approuve_blogentry'), (submitted,), published, ('moderators', 'managers'),) |
|
121 |
|
122 va créé une entité de type ``Transition`` avec le nom `approuve_blogentry` qui sera relié aux entités ``State`` créées précédemment. |
|
123 |
|
124 Dès lors, nous pouvons utiliser l'interface d'administration pour ces opérations. Mais ce n'est pas recommandé à cause de la complexité superflue et du fait que ces changements ne seront locaux qu'à cette instance. |
|
125 |
|
126 En effet, si vous créez les états et les transitions à travers l'interface utilisateur, la prochaine initialisation de la base de données vous oblige à recréer toutes les entités. |
|
127 L'interface utilisateur devrait être seulement connu par vous pour la visualisation des états et transitions, mais ce n'est pas celle appropriée pour définir vos workflows applicatifs. |
|
128 |
|
129 |
|