Blocks: Workflow block
The Workflow system is used at the OU to manage the production of courses and some activities. It comprises a block and a related admin report.
A workflow (for our purposes) is a linear sequence of steps. A step has
- a name
- some instructions;
- a check-list of actions;
- a list of roles who are responsible for performing this step;
- a list of actions that are taken automatically when the step is started/finished, for example assigning roles or changing activity settings.
The system allows the definition of different workflows. Each workflow has
- a name
- a description
- an indication of the type of thing it relates to (e.g. ‘course’, ‘mod_quiz’)
Under Admin -> Plugins -> Blocks -> Workflow, there is an interface for Administrators to define and edit workflows, and to import and export workflow definitions as XML.
To use a workflow to manage the production of, say, a course, you go to the course, and add a workflow block to it. Initially, the block will display a message “There is currently no workflow associated with this course.” with an Add workflow button. Clicking the button allows you to select from any of the workflows that are appropriate for ‘course’.
When the workflow is added to the course, the first step in the workflow becomes active. The workflow block now displays the step instructions for the currently active step; the checklist items as a list of check-boxes; a comments area; a Finish step button; and a link to the workflow overview.
When a step becomes active, all the people responsible for completing the step are sent an email informing them that they should do the step. These people may also get an additional role assigned to them in the context the workflow applies to.
The comments area in the workflow block is a simple editable text area where people working on the step can leave notes for each other.
The Finish step button leads to a confirmation page. If the action is confirmed, then the workflow advances to the next step. When the last step of the workflow is finished, the workflow either stops, or loops back to one of the other steps.
The workflow overview gives an overview of all the steps in this workflow, and the progress through it. The system tracks the timestamp, and the user, each time a step is finished or made active.
The overview page also allows workflow administrators (those with an appropriate capability) to jump the workflow to any particular step.
There is also an admin reports that summarise the workflow across a selection of courses or activities.
Screenshots
a release for Moodle 3.2 is planned?
In current release (2016080200) "email" command in step scripts doesn't play. I obtain many error messages like "eventdata as \stdClass is deprecated. Please use core\message\message instead." or similar.
Thank you!
Roberto
Thank you Tim
Roberto
I would say that the system was not designed with that in mind.
On the other hand, the system is quite well designed. The block is just a view, and most of the view is generated by a renderer, that would be quite easy to reuse. So, it would be quite easy to re-use the back-end code, and some of the bits of view, in another development. You would just need to work it out.
Contexts are used throughout Moodle and have meaning.
The contextid is what ties the instance of the workflow block to some content - i.e. a course, category, activity, block, etc.
If you do this, then you may find that you shoot yourself in the foot should you add the block to different places in the future and that location is one of the 'unique' numbers you've chosen.
Please help in this issue, It's URGENT.
Thanks in advance.
Thank you for your reply in such short time.
I got my mistake. But now I am facing another problem that is:
The steps defined in the workflow should be performed by the roles assigned to that particular step. But when I defined two steps with different roles both roles can perform both the steps which is not as expected. Kindly guide for the same.
The way it works is a little bit complicated. Users will see the button if EITHER they have 'block/workflow:dostep' capability, or if they have one of the step roles.
So, perhaps you need to change the role definitions, so that the users do not have block/workflow:dostep?
Role1- Instructor
Role2- Trainer
Workflow has 2 steps, Step-1 should be performed by Trainer and Step-2 should be performed by Instructor.
Hence step-1 should be visible only to Trainer while step-2 should be visible to Instructor , however step 1 is also visible to Instructor and even he can perform this step which is not desirable... Kindly help me with this issue.
I have another question that is :
Is there any restriction that at a time only 1 workflow can be added on any course?
Thanks in advance
If you really want it to work differently, you could probably do it using the 'When step starts' script to assign a role that Prevents some of the workflow capabilities, to hide the block from people who are not supposed to do this step.
There is a restriction that you can only have one workflow in each context. Therefore, you can have one workflow for each activity, as well as one for the course. Not sure if that helps.