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 six administration pages (or more in the case of admin pages provided by subplugins). Firstly, the users can set general settings in General & subplugin most importantly the time a course is delayed (default half a year).
For a fresh start workflows can only be created in the navigation workflow drafts. Here at the top buttons exist to create a new workflow, backup from workflows can be uploaded (see Import a workflow by xml-file), or workflows can be duplicated (Copy workflow from existing).
Whenever workflows are created they are listed as a draft. It is highly recommended to check the workflow multiple times before activating the workflow! The links at the bottom of the page navigate to the list of activated and deactivated workflows.
In the third navigation item, active workflows (workflows that are running on your instance) are listed. Those are grouped in a table listing all automatic workflows that are triggered without a teacher starting the process. Manual workflows (workflows that have at least one manual trigger) can be started by the teacher of a course.
As the default setting two workflows are active: 1) Exclude delayed courses - which fetches all courses which should not be processed and 2) Exclude side courses - as the site course is used as a starting page (at least for us). The screenshot displays two further workflows which exclude courses without teachers and another one for deleting.
The page has a course search for all courses that are currently triggered or processed by any workflow. Moreover, workflows can still be adjusted depending on the step or trigger, workflows can be deactivated (courses processed are processed until the last step) or aborted (no further steps are taken).
In the navigation item Course backups - backups of courses created by the backup step (not Moodle core) can be recreated.
Delayed courses shows courses currently delayed and Error handling shows courses that failed during a process.
You have two possibilities to define a workflow. You can add a new workflow and start from scratch or you can select an existing workflow definition.
When you want to upload an existing workflow definition, go to Workflow drafts and click the button Upload workflow. Then you can upload a xml-file you downloaded from Workflow Definitions or got from someone else who already uses tool_lifecycle. Note: If the xml-file contains steps or triggers that are not installed at your system, you got errors and the workflow will not work stating "Invalid workflow configuration".
But for now, let's start with a new workflow. For that click the button 'Create new 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, whether they still need a certain course or whether 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 where 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 within 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 passed, 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, whether 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 later workflow (for this the order of the activated workflows is of relevance). One example is the site course. Since you should in general never start a workflow for your site course, there is a default workflow, which will always exclude the site course from any processing.
In your workflow view (following workflow-creation or editing existing one), you have two drop-downs: "Add new trigger instance" and "Add new step instance". 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 a new instance of 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 drafts. There is a button Activate next to your workflow entry, which will activate the workflow (if it has a valid configuration). Through that it will probably be moved to Active workflows. If not have a look at manual workflows below! Every workflow, which is listed at Active automatic workflows, 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, whether they want to trigger a process for this course (or whether 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. Then, 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.
Some steps allow to alter them while workflows are active (e.g. the batch size for creating backups). Otherwise, follow those steps. Active workflows can never change order. 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 two possibilities (icons under column "Actions"):
- Disable workflow (processes keep running): This will just prevent any new process from being started. Usually, we recommend you 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 an email and navigated 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.
Deactivated workflows can only be accessed by clicking the link from Active Workflows or Workflow Drafts.
Of course, you can also copy an active workflow and work on a new version before disabling the old one. So if you need a certain task to continue without any break, this will reduce the downtime 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.
If you want to reuse (e.g. transfer to another instance) or share your workflow, go to Active workflows and click the arrow icon "Backup workflow" to the right of the workflow for which you want to save an XML file.
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 to be allowed to perform the action of starting a process of this manual workflow for the course. The teacher can reach this self-service page through every course's course administration (Course Administration > Manage courses). There teachers see all their courses including the current processing state the courses are in within the running processes. They also can interact with the processes, if required (for instance by the email step). Additionally, as mentioned, they can start new processes if you configured manual workflows and if they have the correct capabilities 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 can view all created backups on the site Site Administration > Plugins > Admin Tools > Life Cycle > Course Backups. There you are also able to restore the selected backups directly.