Recurring Course Proposal: Difference between revisions
Peter Bulmer (talk | contribs) mNo edit summary |
Peter Bulmer (talk | contribs) mNo edit summary |
||
| Line 4: | Line 4: | ||
[[Course_Reset_Proposal]] | [[Course_Reset_Proposal]] | ||
The central pillar of this proposal is to modify core activity completion so that modules | The central pillar of this proposal is to modify core activity completion so that modules themselves can support recurrence, without (necessarily) requiring them to delete user data. | ||
For courses using | For courses using recurrence, the course modules will move through the following states: | ||
* completion_incomplete | * completion_incomplete | ||
* (user completes activity) | * (user completes activity) | ||
| Line 16: | Line 16: | ||
* completion_complete | * completion_complete | ||
(The cm completion table will need an extra field | (The cm completion table will need an extra field timerecurrence to indicate when the CM last recurred). Activities testing user completion will need to consider 'recurring' to be equivilent to 'incomplete' except for the need to only consider user actions after 'timerecurrence'. Eg a requirement that a person complete a quiz, would be assessed as 'user must have completed quiz after date 20/09/2012 12:00z' if the state is 'recurring', and timerecurrance is 20/09/2012 12:00z. | ||
Course completion will need extra fields indicating when the completion expires, and 'recurring' to indicate whether the user is currently re-taking the course. Course completions which are 'recurring' can be updated with new completion details if course completion criteria are met. | Course completion will need extra fields indicating when the completion expires, and 'recurring' to indicate whether the user is currently re-taking the course. Course completions which are 'recurring' can be updated with new completion details if course completion criteria are met. | ||
| Line 22: | Line 22: | ||
Courses completion will need new fields to contain information about | Courses completion will need new fields to contain information about | ||
* How long a course's completion is valid for | * How long a course's completion is valid for | ||
* How long before completion expiry the recurrence event will occur | * How long before completion expiry the recurrence event will occur (if not manually triggered before) | ||
* How long before completion expiry a user can manually start recurrance. | |||
When a recurrance event occurs for a particular user for a particular course, the following will happen: | When a recurrance event occurs for a particular user for a particular course, the following will happen: | ||
| Line 28: | Line 29: | ||
* course completion record would be marked as recurring for that user | * course completion record would be marked as recurring for that user | ||
* relevant course criteria completions deleted, | * relevant course criteria completions deleted, | ||
* cm_completions set to completion_recurring | * cm_completions set to completion_recurring | ||
* user emailed to advise them that they are now able to re-take the course (unless manually triggered) | |||
If the alternate [[Course_Reset_Proposal]] is also implemented, then this reset would occur now as well. Although this should not be necessary except in particular circumstances. | If the alternate [[Course_Reset_Proposal]] is also implemented, then this reset would occur now as well. Although this should not be necessary except in particular circumstances. | ||
The drive behind this proposal is to allow continuous demonstration of a persons compliance with course completion requirements. No data needs to be deleted for the user to re-complete the course, and course completion can be continuous - you don't need to wait for the course to expire before re-completing it. | The drive behind this proposal is to allow continuous demonstration of a persons compliance with course completion requirements. No data needs to be deleted for the user to re-complete the course, and course completion can be continuous - you don't need to wait for the course to expire before re-completing it. | ||
Latest revision as of 00:50, 21 September 2012
See MDL-35335
Alternative/complementary proposal to: Course_Reset_Proposal
The central pillar of this proposal is to modify core activity completion so that modules themselves can support recurrence, without (necessarily) requiring them to delete user data.
For courses using recurrence, the course modules will move through the following states:
- completion_incomplete
- (user completes activity)
- completion_complete
- (separately course completes)
- (separately course completion gets near to expiry)
- completion_recurring
- (user re-completes activity)
- completion_complete
(The cm completion table will need an extra field timerecurrence to indicate when the CM last recurred). Activities testing user completion will need to consider 'recurring' to be equivilent to 'incomplete' except for the need to only consider user actions after 'timerecurrence'. Eg a requirement that a person complete a quiz, would be assessed as 'user must have completed quiz after date 20/09/2012 12:00z' if the state is 'recurring', and timerecurrance is 20/09/2012 12:00z.
Course completion will need extra fields indicating when the completion expires, and 'recurring' to indicate whether the user is currently re-taking the course. Course completions which are 'recurring' can be updated with new completion details if course completion criteria are met.
Courses completion will need new fields to contain information about
- How long a course's completion is valid for
- How long before completion expiry the recurrence event will occur (if not manually triggered before)
- How long before completion expiry a user can manually start recurrance.
When a recurrance event occurs for a particular user for a particular course, the following will happen:
- copy of course completion record put in archive table
- course completion record would be marked as recurring for that user
- relevant course criteria completions deleted,
- cm_completions set to completion_recurring
- user emailed to advise them that they are now able to re-take the course (unless manually triggered)
If the alternate Course_Reset_Proposal is also implemented, then this reset would occur now as well. Although this should not be necessary except in particular circumstances.
The drive behind this proposal is to allow continuous demonstration of a persons compliance with course completion requirements. No data needs to be deleted for the user to re-complete the course, and course completion can be continuous - you don't need to wait for the course to expire before re-completing it.
