Changes between Version 16 and Version 17 of TestManagerForTracPluginWorkflow
- Timestamp:
- Jul 28, 2015, 11:18:10 AM (9 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
TestManagerForTracPluginWorkflow
v16 v17 11 11 Every object which has a workflow defined is created in a "new" state, so every transition should consider this as the first state in the state machine. 12 12 13 14 13 == Example: How to implement Workflow on Test Cases == 15 14 … … 17 16 18 17 All is required it to define the desired workflow steps, a.k.a. the "state machine", in the trac.ini file. 19 A "state machine" is just a definition of the steps (known as states) your art ifacts should go through after they are created, of the actions that are allowed in each state and that may transition the artifact into a different state, and of the operations the system should perform on the artifact, or on anything else, along with these actions.18 A "state machine" is just a definition of the steps (known as states) your artefacts should go through after they are created, of the actions that are allowed in each state and that may transition the artefact into a different state, and of the operations the system should perform on the artefact, or on anything else, along with these actions. 20 19 21 20 A state machine indeed defines three things: 22 21 * States - the 'steps' of the workflow. Note that the first step of any workflow will always be "new". 23 * Transition actions - the User actions avaiable in each state, which may optionally move the art ifact from that state to another.24 * Operations - what the system must perform on the art ifact (but not only) when a certain transition action is triggered.22 * Transition actions - the User actions avaiable in each state, which may optionally move the artefact from that state to another. 23 * Operations - what the system must perform on the artefact (but not only) when a certain transition action is triggered. 25 24 26 25 The three elements above are specified in the trac.ini file with the following syntax. … … 34 33 For resource type we mean the "realm" string used for resource registration into the Trac environment. 35 34 36 Resource type names for the Test Manager plugin art ifacts are the following:35 Resource type names for the Test Manager plugin artefacts are the following: 37 36 * testcatalog 38 37 * testcase … … 40 39 * testplan 41 40 42 For example, to start the definition of a state machine for Test Case, add the following into the trac.ini file: 43 [testcase-resource_workflow] 44 41 For example, to start the definition of a state machine for Test Case, add `[testcase-resource_workflow]` to your `trac.ini` file: 45 42 46 43 === Definition of transition actions and states: === 47 44 48 In the section started with the row above you can define the state machine for the specified art ifact.49 50 To define states of the workflow and actions that allow for moving art ifacts from one state to another - so said transition actions, use the following syntax:45 In the section started with the row above you can define the state machine for the specified artefact. 46 47 To define states of the workflow and actions that allow for moving artefacts from one state to another - so said transition actions, use the following syntax: 51 48 52 49 {{{ … … 57 54 * Define a state named '''old state''' 58 55 * Define a state named '''new state''' 59 * Define a transition action '''action''' that should be available in the state '''old state''' and that, when chosen by the User, will move the art ifact into the '''new state'''.56 * Define a transition action '''action''' that should be available in the state '''old state''' and that, when chosen by the User, will move the artefact into the '''new state'''. 60 57 61 58 Special cases: … … 63 60 * You can specify that an action should be available in more than one state by separating them with a comma, as in "asleep,calm -> dead". 64 61 65 66 62 === Definition of operations to be performed along with specified actions === 67 63 68 You can specify that every time an art ifact is moved from one state to another by means of a transition action, the system should perfomrone or more operations.64 You can specify that every time an artefact is moved from one state to another by means of a transition action, the system should perform one or more operations. 69 65 70 66 There is a set of [wiki:TestManagerPluginWorkflowOperations out-of-the-box operations] available, but more operations can be provided with your or other plugins by implementing the IWorkflowOperationProvider interface. … … 87 83 '''action'''.permissions = '''permission1''','''permission2''',... 88 84 89 [[BR]] 90 Defining your desired workflow in the trac.ini file '''is all that is required''' to mandate a workflow to the artifacts provided with the [wiki:TestManagerForTracPlugin TestManager] plugin. 91 92 [[BR]] 85 Defining your desired workflow in the trac.ini file '''is all that is required''' to mandate a workflow to the artefacts provided with the [wiki:TestManagerForTracPlugin TestManager] plugin. 86 93 87 === Example === 94 88 … … 105 99 [[BR]] 106 100 107 {{{ 101 {{{#!ini 108 102 [testcase-resource_workflow] 109 103 sleep = new -> asleep … … 121 115 }}} 122 116 123 [[BR]][[BR]]124 117 == Out-of-the-box operations == 118 125 119 A set of predefined, [wiki:TestManagerPluginWorkflowOperations out-of-the-box operations] is available, to enrich your workflows not only with state management, but also with side-effects to occur along with state changes. 126 120 127 [[BR]][[BR]]128 121 == How to provide custom operations == 129 122 … … 134 127 To be able to provide custom workflow operations, your Trac Component must implement the IWorkflowOperationProvider interface. 135 128 136 Let's take a look at a sample operation provider, which is included in the [wiki:TestManagerForTracPlugin TestManager] plugin .137 138 {{{ 129 Let's take a look at a sample operation provider, which is included in the [wiki:TestManagerForTracPlugin TestManager] plugin: 130 131 {{{#!python 139 132 from tracgenericworkflow.api import IWorkflowOperationProvider 140 133 … … 171 164 }}} 172 165 173 174 166 As you can see, it's not much code to write. Let's go through it. 175 167 … … 187 179 * The name of the operation to be rendered (this in case the provider has stated to provide more than once). 188 180 * The ResourceWorkflowState object representing the current state of the resource in the workflow. 189 * The Resource object representing the art ifact instance being subject to the workflow.181 * The Resource object representing the artefact instance being subject to the workflow. 190 182 191 183 This method must return two results: … … 199 191 * The name of the transition action that is associated with this operation in the trac.ini file. 200 192 * The name of the operation to be performed (this in case the provider has stated to provide more than once). 201 * The name of the old workflow state from which the art ifact is being moved.202 * The name of the new workflow state to which the art ifact is being moved.193 * The name of the old workflow state from which the artefact is being moved. 194 * The name of the new workflow state to which the artefact is being moved. 203 195 * The ResourceWorkflowState object representing the current state of the resource in the workflow. 204 * The Resource object representing the art ifact instance being subject to the workflow.196 * The Resource object representing the artefact instance being subject to the workflow. 205 197 206 198 There are no requirements as to what the provider must or can do inside this method, except from what's specified next. … … 208 200 It is '''NOT allowed''' to modify the res_wf_state object. 209 201 210 This is it. You have added a workflow and your custom operations to the Test Case artifact. 211 212 Of course, you can do the same with the three other artifacts in the [wiki:TestManagerForTracPlugin TestManager] plugin, namely Test Catalogs, Test Plans and Test Cases in Plan (i.e. with a status). 213 214 [[BR]][[BR]] 215 216 == Extend workflow support to any of your artifacts == 217 218 As said, Test artifacts already have workflow support. To turn it on, all you must do is define the desired workflow in the trac.ini file, as described above. 219 220 But there is more you can do with the TracGenericWorkflow standalone plugin (remember it requires TracGenericClass plugin to be installed, anyway), you can add workflow support to any of your artifacts inside Trac. 202 This is it. You have added a workflow and your custom operations to the Test Case artefact. 203 204 Of course, you can do the same with the three other artefacts in the [wiki:TestManagerForTracPlugin TestManager] plugin, namely Test Catalogs, Test Plans and Test Cases in Plan (i.e. with a status). 205 206 == Extend workflow support to any of your artefacts == 207 208 As said, Test artefacts already have workflow support. To turn it on, all you must do is define the desired workflow in the trac.ini file, as described above. 209 210 But there is more you can do with the TracGenericWorkflow standalone plugin (remember it requires TracGenericClass plugin to be installed, anyway), you can add workflow support to any of your artefacts inside Trac. 221 211 222 212 To do that, you should do the following steps: 223 213 224 1. Define your desired workflow - ''explained above'' 225 1. Define any custom operations you may provide on your art ifacts - ''explained above''214 1. Define your desired workflow - ''explained above''. 215 1. Define any custom operations you may provide on your artefacts - ''explained above''. 226 216 1. '''Display the workflow markup into your web pages'''. This is what this section is about. 227 217 228 There are several ways how you can provide markup to web pages in Trac. Here, I'll explain the way I do it in the [wiki:TestManagerForTracPlugin TestManager] plugin, which is by means of the ITemplateStreamFilter.218 There are several ways how you can provide markup to web pages in Trac. Here, I'll explain the way I do it in the [wiki:TestManagerForTracPlugin TestManager] plugin, which is by means of the '''ITemplateStreamFilter'''. 229 219 230 220 To do this, you must: 231 232 1. Implement the ITemplateStreamFilter interface 221 1. Implement the ITemplateStreamFilter interface. 233 222 1. When you need to display the markup for the workflow support - i.e. the list of available transition actions in the current resource state and the associated operations - call the ResourceWorkflowSystem.get_workflow_markup() method to get the markup, then just add it to your page. 234 223 235 You may ask... this is it??? 236 237 Yes! You don't have to do anything to: 224 In other words, you don't have to do anything to: 238 225 * Manage you resource states 239 226 * Handle transitions 240 227 * Manage operations 241 228 242 all this is automatically performed by the plugin.243 244 So, let's take a look at (a simplified version of) how the [wiki:TestManagerForTracPlugin TestManager] plugin incorporates this web interface support .245 246 {{{ 229 All this is automatically performed by the plugin. 230 231 So, let's take a look at (a simplified version of) how the [wiki:TestManagerForTracPlugin TestManager] plugin incorporates this web interface support: 232 233 {{{#!python 247 234 from trac.web.api import ITemplateStreamFilter 248 235 from tracgenericworkflow.api import ResourceWorkflowSystem … … 281 268 * req: the http request 282 269 * base_href: an href string pointing to the base of your project - e.g. in the context of a wiki page, '..' returns up to your project's base URL. 283 * realm: the art ifact's resource type - e.g. 'testcase' in the examples above.270 * realm: the artefact's resource type - e.g. 'testcase' in the examples above. 284 271 * resource: the actual Trac resource instance object of the workflow. 285 272 286 Note: [wiki:TestManagerForTracPlugin TestManager] art ifact resources are made so that their resource ID is a string representation of their key properties, in the form of a JSON dictionary.287 This is why you see the following code, where to build a Trac Resource corresponding to a [wiki:TestManagerForTracPlugin TestManager] art ifact, I first build the Resource ID as the string representation of the artifact's key properties, then use it to create the Resource:273 Note: [wiki:TestManagerForTracPlugin TestManager] artefact resources are made so that their resource ID is a string representation of their key properties, in the form of a JSON dictionary. 274 This is why you see the following code, where to build a Trac Resource corresponding to a [wiki:TestManagerForTracPlugin TestManager] artefact, I first build the Resource ID as the string representation of the artefact's key properties, then use it to create the Resource: 288 275 289 276 {{{ … … 301 288 2. Being notified of state transitions => IWorkflowTransitionListener 302 289 303 304 290 === IWorkflowTransitionAuthorization === 305 291 306 {{{ 292 {{{#!python 307 293 class IWorkflowTransitionAuthorization(Interface): 308 294 """ … … 326 312 === IWorkflowTransitionListener === 327 313 328 {{{ 314 {{{#!python 329 315 class IWorkflowTransitionListener(Interface): 330 316 """ … … 343 329 """ 344 330 }}} 345