Details
-
Type:
Bug
-
Status:
Open
-
Priority:
Major
-
Resolution: Unresolved
-
Affects Version/s: 1.9.5
-
Fix Version/s: None
-
Component/s: Backup
-
Labels:None
-
Affected Branches:MOODLE_19_STABLE
Description
currently restore works like so:
1. Login as admin
2. Create a sample course (course A) that starts on May 1, 2009 with one assignment due on May 7, 2009.
3. Take a backup of the course and download the backup file.
4. Upload the backup file to another course (course B) with a different start date.
5. Restore the backup to a new course using the default start date (May 1, 2009).
6. Look at the details of the assignment in the new course. The due date should still be May 7, 2009 but will instead be something different. (It will be offset relative to course B instead of using the date provided in the restore.)
how it seems to be expected to work"
If backup A is created from a course A then the restore function is used from course B:
If a new course is created from backup A it will use the backups start date and the date entered in the form to set the offset for activities or events.
If the backup is restoring to the current course and deleting it first then it will use the backups start date and course B's start date.
If the backup is restoring to an existing course C and deleting it first then it will use the backup A's start date and C's start date.
If the backup is restoring to the current course and adding data to it then for all the added data the offset will be from backup A and the date submitted in the form.
If the backup is restoring to an existing course and adding data to it then for all the added data and the offset will be from backup A and the date submitted in the form.
This is how most people probably assumed the backup system worked. This patch will allow you to use the restore forms start date to offset the course and it's activities as expected.
Attachments
Issue Links
Activity
- All
- Comments
- History
- Activity
- Source
- Test Sessions
Hi, while I agree 100% that we must discuss and decide about the way rolling dates is performing (when to use backup one or course one as start point to find the offset), I wouldn't recommend the suggested patch at all!
Since some days ago we have one checksum mechanism built in the restore process, so we are able to detect if something has been lost in the restore variables (see MDL-18469). Also we have reverted and fixed (in all our tests) the original problem of dates rolling badly (see MDL-17469).
And the patch suggested in this bug, affecting the restore.php script (that shouldn't have any sort of $restore transformation, by design) can cause those checksums to fail badly, preventing any restore execution to happen.
See, related, this discussion: http://moodle.org/mod/forum/discuss.php?d=134239
So I would recommend to:
1) Revert this patch in your servers.
2) Check that "normal" roll of dates (always based in backup course info) is working ok.
3) Discuss in this bug about the proposal of relying into target course date for rolling dates.
Ciao 
The same problem Iam experiencing here with our moodle installation 1.9.5