Documentation for Administrators
Download the plugin through Github or soon through the Moodle Plugin Directory.
Put the contents of the plugin in the folder admin/tool/lifecycle. (Make sure you write lifecycle with an f ;) )
A small set of useful subplugins is already contained in the basic installation. If you need additional plugins you can find a list of available plugins here: List of Subplugins
There are two different kinds of subplugins:
- Step subplugins go under
admin/tool/lifecycle/step. - Trigger subplugins go under
admin/tool/lifecycle/trigger. What those subplugins do is explained later. For the start, it is enough if you just install the main plugin!
The plugin has mainly administration pages. There are in total five administration pages. The most important for the beginning is the site Site Administration > Plugins > Admin Tools > Life Cycle > Workflow Settings.
The page comes with three tables. Let's forget about the first two for a moment and start with the third.
The table Workflow Definitions is your sceatch board. Here you can start configure the tasks you want the lifecycle plugin to do. It does not have any effect unless you activate your workflow. So feel free to look around.
#How to create a workflow? You have to possibilities to define a workflow. You can add a workflow and start from scratch or you can select a finished workflow definition from here: Workflow Definitions When you want to upload an existing workflow definition, just upload the xml-file you downloaded under Upload Workflow
But for now, let's start with a new workflow. For that click on 'Add Workflow'. In the first page, you have to enter a title, which is for your eyes only, and a display title. The latter one will be displayed to the user, if they have to interact with the system in any part of the process. For instance, they could be asked per mail, if they still need a certain course or if we can delete it. So while the title could include some version information e.g. Delete courses - Version 1.0-2019 the display title could read yearly course cleanup. This information can be altered later so don't bother to much with the naming right now.
The next step is were the magic happens. ;) Here you can start defining the conditions under which a process is run and what steps should be executed during it.
A workflow or a workflow definition is what you configure in the admin settings or the view in which you are right now. A process on the other hand is an instance of this definition, which runs based on one of your courses. So the workflow is the blueprint, while the process is what is really executed.
The steps you define for a workflow are small atomic actions, which should be executed for a course. For instance, creating a backup, deleting a course or asking a user for her interaction. They have a strict order in which they are executed and one step is only started after the previous step is finished. Thus, make sure you create a backup before you delete a course! ;)
A trigger represents the conditions under which a course is run. These conditions could be the time which past, since the start of the course, the category a course does or does not belong to or the current date. For the latter, you might want to start certain tasks only once per semester or per year. The moodle cron checks repeatedly, if there is any course, for which all conditions specified by the triggers are met. If so, for this course a process is started based on the current definition of your workflow.
If a course is passed to a trigger, this trigger can, however, return three different results. The first result is NEXT. This means, the course does not meet the requirements of the trigger. In this case, no process for this workflow will be started for the course.
The next result is Trigger. If all configured triggers agree upon this result (e.g. the course belongs to the correct category, it is the correct date and the course is old enough), then a process is started.
The last result is Exclude. For special courses it might be interesting for you, to exclude them completely from any workflow of the whole lifecycle plugin. If any trigger returns an Exclude state for a course, this course will not be processed for this workflow or any other workflow. One example is the site course. Since you should never start a workflow for your site course, there is a default workflow, which will always exclude the site course from any processing. (The order of the workflows is important here, which will be described later!)
In your current view, you have two dropdown at the top. Those contain all steps/triggers you installed in your system. If you select one of those, you will be redirected to a new page, in which you can configure the selected subplugin. When you save the instance form, you are redirected back to the configuration page of your workflow, now with a new entry. Steps and triggers can be added this way and they can be deleted and edited. The sort order of the trigger has usually no effect. However, the triggers which are listed on top, will be requested first. So if your specific trigger has some complicated calculations, you might want to reduce the number of courses processed by this trigger by listing other triggers first.
If you want to activate your workflow you can do that on the site Site Administration > Plugins > Admin Tools > Life Cycle > Workflow Settings. There is a button next to your workflow entry, which will activate the workflow. Through that it will probably be moved to the first table. If not have a look at manual workflows below! Every workflow, which is listed in the first table, will be regularly called by the cron job.
Be aware that there can only be one process for a course at the time. This is why for each course, the workflows are requested one by one, if they want to trigger a process for this course (or if they want to exclude it completely for all succeeding workflows). This is why the order of the workflows matters. Workflows at the top are called first.
If a course meets all requirements by the triggers of the workflow, a process will be started for this course. In this process all steps are executed one by one. If you are tackling the use case to get rid of old courses, there might be quite a lot of courses to process initially. For this reason many subplugins, which have time consuming tasks (such as creating a backup or deleting a course) are done in small batches. Others such as sending a mail to the teachers of your old courses on the other hand are done together to not spam your teachers with one mail every minute. All currently running courses can be viewed under Site Administration > Plugins > Admin Tools > Life Cycle > Active Processes.
Active workflows can not be altered in any way. This might completely screw up already running processes. Instead the right way is to disable your workflow, copy it, alter the copy and activate it again. For disabling a workflow you are offered to possibilities:
- Disable workflow (processes keep running): This will just prevent any new process to be started. Usually we recommend you to select this alternative!
- Disable workflow (abort processes. Maybe unsafe!): This terminates (performs a rollback) on all running processes of this workflow, before disabling it. This could irritate your users, for instance if they received a email and navigate to the self-service to respond to the system, but there is no longer a process for this course. However, if you made a mistake in the definition of your workflow and definitely want no process to be executed any further, this is the option to go! :) For disabled/deactivated workflows no new process will be started. However, depending on your choice, already running processes will continue running under the old workflow definition.
All deactivated workflows are stored under Site Administration > Plugins > Admin Tools > Life Cycle > Deactivated Workflows.
Of course, you can also first copy an active workflow and work on a new version before you disable the old one. So if you need a certain task to continue without any break, this will reduce the down time of your task.
Hint: To not lose the overview of all your workflow variants, you should add version numbers to the title of your workflows.
Manual workflows are tasks, which are not run automatically but are offered as a self-service to your users. To create a manual workflow you have to add a manual trigger to it. A manual trigger defines the capability a user must have in the context of the course in order to be allowed to perform the action of starting a process of this manual workflow for the course. The teacher is able to reach this self-service page through every courses' course administration (Course Administration > Course Life Cycle). There they see all their courses including the current processing state the courses are in currently running processes. They also have the possibility to interact with the processes, if required (for instance by the email step) and they can start new processes if you configured manual workflows and they have the right to do so.
The backups created by the step createbackup are not stored in the general backup store or in the moodle files folder but in a separate folder in your Moodledata under lifecycle_backups. This way you could put it on a different server by mounting another drive into this location. Through the moodle administration, you are able to view all created backups on the site Site Administration > Plugins > Admin Tools > Life Cycle > Course Backups. There you are also able to directly restore the selected backups.