Moodle

Manual grade items with calculations not restoring properly.

Details

  • Type: Bug Bug
  • Status: Closed Closed
  • Priority: Major Major
  • Resolution: Duplicate
  • Affects Version/s: 1.9
  • Fix Version/s: 1.9.1
  • Component/s: Backup, Gradebook
  • Labels:
    None
  • Affected Branches:
    MOODLE_19_STABLE
  • Fixed Branches:
    MOODLE_19_STABLE

Description

Manual gradebook items that use calculations do not restore properly into Moodle (most of the time). The calculation string restores to the database identical to how it reads in the xml backup file.

Example: Say my moodle.xml backup file says the calculation of manual grade item # 300 is:

=sum(##gi259##,##gi260##,##gi261##,##gi262##)

But grade_item with id 259 in the moodle.xml file doesn't always receive the same ID when put into the database (in cases where the ID is already taken). The restore process needs to wait to process the calculation string for any manual grade_item for all the other grade items to be inserted into the database.

Meaning, items 259, 260, 261, and 262 need to be inserted into the database before we can attempt to re-calculate the calculation for manual item #300.

The suggested fix involves traversing through each item as normal, and saving any manual items into an array that will then be checked and processed after all grade_items from xml have been inserted into the database.

All changes take place in backup/restorelib.php within the function restore_create_gradebook. Keep in mind the change may not be up to Moodle standards. There are probably a few places where current functions should be used instead but for what it's worth, this code works.

The included text file is only of the function restore_create_gradebook in restorelib.php and code additions start with /added code/ and end with a comment as well.

EDIT:
Oops, forgot to mention how it works. The new code takes the calculation string that references old_ids of each grade item and parses each ##gi***## replacing the old_id (***) with the new_id using backup_getid() to retrieve the new id. By waiting until all grade items are restored to re-calculate it ensures that we have the correct ID's in the calculation string. I've only tested with the sum function, but the code only replaces ID's so any function should work.

Attachments

  1. Text File
    restore_create_gradebook.txt
    04/Jul/08 12:03 AM
    60 kB
    Tom Trueluk
  2. File
    restorelib.php.diff
    10/Feb/09 6:01 AM
    6 kB
    Tom Trueluk
  1. autoid.jpg
    64 kB
    01/Oct/08 4:39 PM

Issue Links

This issue is a clone of:
MDL-16509 CLONE -Manual grade items with calculations not restoring properly. Major Closed
This issue duplicates:
MDL-14841 Grade item calculation formula not restored properly Major Closed

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Petr Škoda (skodak) added a comment - - edited

hello,

this is not how it is supposed to work, it does:
1/ during backup the formulas are converted to =[[someidnubmer]]*[[otheridnumer]]
2/ during restore the formula is not changed
3/ when formula first used it is converted back to =##gi123##*##gi321##

This did not work in 1.9.0 , but it was fixed in 1.9.1

Both backup and restore is buggy in 1.9.0, please upgrade to latest 1.9.1+

Show
Petr Škoda (skodak) added a comment - - edited hello, this is not how it is supposed to work, it does: 1/ during backup the formulas are converted to =[[someidnubmer]]*[[otheridnumer]] 2/ during restore the formula is not changed 3/ when formula first used it is converted back to =##gi123##*##gi321## This did not work in 1.9.0 , but it was fixed in 1.9.1 Both backup and restore is buggy in 1.9.0, please upgrade to latest 1.9.1+
Hide
Permalink
Petr Škoda (skodak) added a comment -

Closing as duplicate,
please reopen in case you can reproduce this with latest cvs version, I tested it again and works for me, I remember several other people tested this before the 1.9.1 release.

Thanks for the report,
Petr

Show
Petr Škoda (skodak) added a comment - Closing as duplicate, please reopen in case you can reproduce this with latest cvs version, I tested it again and works for me, I remember several other people tested this before the 1.9.1 release. Thanks for the report, Petr
Hide
Permalink
Katarzyna Potocka added a comment -

problem is that it is not working for us correctly....version 1.9.2+
within courses with calculations for grade categories, the id's are not resored correctly and there is an Error message in the grade overview report for teachers. For courses with many calculations the restoring of the course is not working...it just stops in the middle without bigreport and only the resources are restored...clicking on grade in the admin box doesn't work.....
so I would like to see this problem reopened

thanks
Katarzyna Potocka

Show
Katarzyna Potocka added a comment - problem is that it is not working for us correctly....version 1.9.2+ within courses with calculations for grade categories, the id's are not resored correctly and there is an Error message in the grade overview report for teachers. For courses with many calculations the restoring of the course is not working...it just stops in the middle without bigreport and only the resources are restored...clicking on grade in the admin box doesn't work..... so I would like to see this problem reopened thanks Katarzyna Potocka
Hide
Permalink
Tim Hunt added a comment -

Reopening.

Katarzyna, it would be really helpful if you could post step-by-step instructions for how to reproduce this problem. Something like:

-------------------------
1. Create a new course.
2. Add to the gradebook [write details here]
3. [Write anything else that needs to be set up.]
4. Backup.
5. Restore to a new course.

What actually happens:

[Copy and paste any error messages here exactly.]

What should happen:

[Write here what you think should have happened, if there is any doubt about why what actually happened is wrong.]
-------------------------

Thanks.

Show
Tim Hunt added a comment - Reopening. Katarzyna, it would be really helpful if you could post step-by-step instructions for how to reproduce this problem. Something like: ------------------------- 1. Create a new course. 2. Add to the gradebook [write details here] 3. [Write anything else that needs to be set up.] 4. Backup. 5. Restore to a new course. What actually happens: [Copy and paste any error messages here exactly.] What should happen: [Write here what you think should have happened, if there is any doubt about why what actually happened is wrong.] ------------------------- Thanks.
Hide
Permalink
Katarzyna Potocka added a comment -

Well I'm not sure if I can reproduce the problem myself but I can try to explain it a little bit better:

The problem was when we tried to export (out of our test moodle) and import (into are runnign system) a
course that was created in the test system. It was using the new gradebook and its possibility
to make different grade categories by using =sum or anything else...
Moodle 1.9.2+ (Build: 20080825)

The export worked fine (without looking at the result files).
During the import (running for 8h!!!!!!) moodle just stopped, crashed and showed blank screen.

After you just relogged in the course was there but everything that was related with the grading
(assignment view, grades in the admin block, etc.) was damaged and showing blank screens (after very long loading time).

During my search I recognised that the entries in the database -> "mdl_grade_items"
column "calculation" were damaged....
Moodle gives automatically some of the items within the gradebook ids (I can't recognise why),
the other items have to be given ids by course creator or teacher....this are two different
database entries, the first one looks in the calculation field like =max([[18722]],.....) and the second one
=max(##gi3898##,##gi3899##). I think that the import should restore the ids correctly but does mix up both, so that
the calculation entry within the database looks for example like:
=max([[18722]],##gi3898##,##gi3899##)
After looking up the correct ids in the databse, changing them to ##gi...## everything works (very slowly)
but fine.

I hope this describes the problem a little bit better!

Show
Katarzyna Potocka added a comment - Well I'm not sure if I can reproduce the problem myself but I can try to explain it a little bit better: The problem was when we tried to export (out of our test moodle) and import (into are runnign system) a course that was created in the test system. It was using the new gradebook and its possibility to make different grade categories by using =sum or anything else... Moodle 1.9.2+ (Build: 20080825) The export worked fine (without looking at the result files). During the import (running for 8h!!!!!!) moodle just stopped, crashed and showed blank screen. After you just relogged in the course was there but everything that was related with the grading (assignment view, grades in the admin block, etc.) was damaged and showing blank screens (after very long loading time). During my search I recognised that the entries in the database -> "mdl_grade_items" column "calculation" were damaged.... Moodle gives automatically some of the items within the gradebook ids (I can't recognise why), the other items have to be given ids by course creator or teacher....this are two different database entries, the first one looks in the calculation field like =max([[18722]],.....) and the second one =max(##gi3898##,##gi3899##). I think that the import should restore the ids correctly but does mix up both, so that the calculation entry within the database looks for example like: =max([[18722]],##gi3898##,##gi3899##) After looking up the correct ids in the databse, changing them to ##gi...## everything works (very slowly) but fine. I hope this describes the problem a little bit better!
Hide
Permalink
Tom Trueluk added a comment -

My initial fix was replacing the grade_item ID's in manual grade item calculation strings with new grade_item ID's which are created during the restore. Now the restore process does what Katarzyna is suggesting as well. The calculation string is populated with [[modIdnumber]], however the restored grade_item associated with each module isn't given an idnumber in the gradebook. There is code in restorelib.php which sets this ( $dbrec->idnumber = $cm->idnumber; , where $dbrec is a grade_item being restored) but that idnumber never makes it into the database. This makes the calculation strings invalid, and "ERROR" replaces the value which should appear in the calculated column when one views the gradebook.

I'm including a diff file for /backup/restorelib.php version 1.283.2.62 with the fix.

Show
Tom Trueluk added a comment - My initial fix was replacing the grade_item ID's in manual grade item calculation strings with new grade_item ID's which are created during the restore. Now the restore process does what Katarzyna is suggesting as well. The calculation string is populated with [[modIdnumber]], however the restored grade_item associated with each module isn't given an idnumber in the gradebook. There is code in restorelib.php which sets this ( $dbrec->idnumber = $cm->idnumber; , where $dbrec is a grade_item being restored) but that idnumber never makes it into the database. This makes the calculation strings invalid, and "ERROR" replaces the value which should appear in the calculated column when one views the gradebook. I'm including a diff file for /backup/restorelib.php version 1.283.2.62 with the fix.
Hide
Permalink
Petr Škoda (skodak) added a comment -

retested, works fine for me
it is possible that the calculations are not restored properly if the restore fails to complete.

thanks for the info

Show
Petr Škoda (skodak) added a comment - retested, works fine for me it is possible that the calculations are not restored properly if the restore fails to complete. thanks for the info
Hide
Permalink
Petr Škoda (skodak) added a comment -

before reopening please submit here a sample backup file that demonstrates the problem (or mail it to me directly - info at skodak dor org)
thanks

Show
Petr Škoda (skodak) added a comment - before reopening please submit here a sample backup file that demonstrates the problem (or mail it to me directly - info at skodak dor org) thanks

People

Vote (2)
Watch (3)

Dates

  • Created:
    Updated:
    Resolved:
Atlassian JIRA (v4.4.3#663-r165197) | Report a problem
Powered by a free Atlassian JIRA open source license for Moodle. Try JIRA - bug tracking software for your team.