1 .. -*- coding: utf-8 -*- |
|
2 |
|
3 Workflow definition |
|
4 ====================== |
|
5 |
|
6 On peut mettre une condition rql ou/et un groupe auquel doit appartenir l'utilisateur. |
|
7 |
|
8 Si on met à la fois un(ou plusieurs) groupe et une condition RQL, il faut que les deux soient respectés. |
|
9 |
|
10 Si on met plusieurs groupes, il faut que l'utilisateur soit dans un des groupes. |
|
11 |
|
12 Pour la condition RQL sur une transition, on peut y mettre les substitutions suivantes : |
|
13 |
|
14 * `%(eid)s`, eid de l'objet |
|
15 * `%(ueid)s`, eid de l'utilisateur qui fait la requête |
|
16 * `%(seid)s`, eid de l'état courant de l'objet |
|
17 |
|
18 Dans le script de création d'un workflow, penser à mettre `_()` autour des noms d'états et de transitions |
|
19 pour que ceux si soient pris en compte par les scripts de gestion des catalogues i18n. |
|
20 |
|
21 General |
|
22 ------- |
|
23 |
|
24 A workflow can be defined in a `LAX` application thanks to the system |
|
25 entities ``State`` and ``Transition``. Those are defined within all |
|
26 LAX application and can be set-up through the main administrator interface. |
|
27 |
|
28 Once your schema is defined, you can start creating the set of states and |
|
29 the required transitions for your applications entities. |
|
30 |
|
31 You first need to define the states and then the transitions between those |
|
32 to complete your workflow. |
|
33 |
|
34 A ``State`` defines the status of an entity. While creating a new state, |
|
35 you will be first given the option to select the entity type the state |
|
36 can be applied to. By choosing ``Apply``, a new section will be displayed |
|
37 in the editing screen to enable you to add relation to the state you are |
|
38 creating. |
|
39 |
|
40 A ``Transition`` is also based on an entity type it can be applied to. |
|
41 By choosing ``Apply``, a new section will be displayed in the editing |
|
42 screen to enable you to add relation to the transition you are |
|
43 creating. |
|
44 |
|
45 At the transition level you will also define the group of user which can |
|
46 aplly this transition to an object. |
|
47 |
|
48 |
|
49 Example of a simple workflow |
|
50 ---------------------------- |
|
51 |
|
52 Please see the tutorial to view and example of a simple workflow. |
|
53 |
|
54 |
|
55 [Create a simple workflow for BlogDemo, to have a moderator approve new blog |
|
56 entry to be published. This implies, specify a dedicated group of blog |
|
57 moderator as well as hide the view of a blog entry to the user until |
|
58 it reaches the state published] |
|
59 |
|
60 Set-up a workflow |
|
61 ----------------- |
|
62 |
|
63 Before starting, make sure you refresh your mind by reading [link to |
|
64 definition_workflow chapter]. |
|
65 |
|
66 We want to create a workflow to control the quality of the BlogEntry |
|
67 submitted on your application. When a BlogEntry is created by a user |
|
68 its state should be `submitted`. To be visible to all, it needs to |
|
69 be in the state `published`. To move from `submitted` to `published` |
|
70 we need a transition that we can name `approve_blogentry`. |
|
71 |
|
72 We do not want every user to be allowed to change the state of a |
|
73 BlogEntry. We need to define a group of user, `moderators`, and |
|
74 this group will have appropriate permissions to approve BlogEntry |
|
75 to be published and visible to all. |
|
76 |
|
77 There are two ways to create a workflow, form the user interface, |
|
78 and also by defining it in ``migration/postcreate.py``. This script |
|
79 is executed each time a new ``./bin/laxctl db-init`` is done. |
|
80 If you create the states and transitions through the user interface |
|
81 this means that next time you will need to initialize the database |
|
82 you will have to re-create all the entities. |
|
83 We strongly recommand you create the workflow in ``migration\postcreate.py`` |
|
84 and we will now show you how. |
|
85 The user interface would only be a reference for you to view the states |
|
86 and transitions but is not the appropriate interface to define your |
|
87 application workflow. |
|
88 |
|
89 Update the schema |
|
90 ~~~~~~~~~~~~~~~~~ |
|
91 To enable a BlogEntry to have a State, we have to define a relation |
|
92 ``in_state`` in the schema of BlogEntry. Please do as follows, add |
|
93 the line ``in_state (...)``:: |
|
94 |
|
95 class BlogEntry(EntityType): |
|
96 title = String(maxsize=100, required=True) |
|
97 publish_date = Date(default='TODAY') |
|
98 text_format = String(meta=True, internationalizable=True, maxsize=50, |
|
99 default='text/rest', constraints=[format_constraint]) |
|
100 text = String(fulltextindexed=True) |
|
101 category = String(vocabulary=('important','business')) |
|
102 entry_of = SubjectRelation('Blog', cardinality='?*') |
|
103 in_state = SubjectRelation('State', cardinality='1*') |
|
104 |
|
105 As you updated the schema, you will have re-execute ``./bin/laxctl db-init`` |
|
106 to initialize the database and migrate your existing entities. |
|
107 [WRITE ABOUT MIGRATION] |
|
108 |
|
109 Create states, transitions and group permissions |
|
110 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ |
|
111 |
|
112 At the time the ``postcreate.py`` script is executed, several methods |
|
113 can be used. They are all defined in the ``class ServerMigrationHelper``. |
|
114 We will only discuss the method we use to create a wrokflow here. |
|
115 |
|
116 To define our workflow for BlogDemo, please add the following lines |
|
117 to ``migration/postcreate.py``:: |
|
118 |
|
119 _ = unicode |
|
120 |
|
121 moderators = add_entity('EGroup', name=u"moderators") |
|
122 |
|
123 submitted = add_state(_('submitted'), 'BlogEntry', initial=True) |
|
124 published = add_state(_('published'), 'BlogEntry') |
|
125 |
|
126 add_transition(_('approve_blogentry'), 'BlogEntry', (submitted,), published, ('moderators', 'managers'),) |
|
127 |
|
128 checkpoint() |
|
129 |
|
130 ``add_entity`` is used here to define the new group of users that we |
|
131 need to define the transitions, `moderators`. |
|
132 If this group required by the transition is not defined before the |
|
133 transition is created, it will not create the relation `transition |
|
134 require the group moderator`. |
|
135 |
|
136 ``add_state`` expects as the first argument the name of the state you are |
|
137 willing to create, then the entity type on which the state can be applied, |
|
138 and an optionnal argument to set if the state is the initial state |
|
139 of the entity type or not. |
|
140 |
|
141 ``add_transition`` expects as the first argument the name of the |
|
142 transition, then the entity type on which we can apply the transition, |
|
143 then the list of possible initial states from which the transition |
|
144 can be applied, the target state of the transition, and the permissions |
|
145 (e.g. list of the groups of users who can apply the transition). |
|
146 |
|
147 .. image:: images/lax-book.03-transitions-view.en.png |
|
148 |
|
149 You can now notice that in the actions box of a BlogEntry, the state |
|
150 is now listed as well as the possible transitions from this state |
|
151 defined by the workflow. This transition, as defined in the workflow, |
|
152 will only being displayed for the users belonging to the group |
|
153 moderators of managers. |
|
154 |
|
155 |
|