Now this function works following this:
- Iterate over every quiz category in the course (following parent-child relationships).
- If the category is being used*, move it to site level (under a container category) and
mark it as published.
- If the category isn't being used, remove** it completely (questions, instances...) and
re-parent its child categories.
- Feedback is shown in a table detailing all the changes performed.
* One category is being used if it has one question that is being used in any quiz,
independently of its publish status.
** Removal of categories (and associated questions) has benn improved but, it won't
be perfect until bug 3366 was solved.
Tested against some large courses with reused questions and multiple levels of
categories. Seems to work but
PLEASE TEST IT AND SEND ANY FEEDBACK TO BUG 2459
(http://moodle.org/bugs/bug.php?op=show&bugid=2459)
Exactly this function is going to be used in the upgrade script to solve
the orphan categories issue and it must work perfectly!
Merged from MOODLE_15_STABLE
against quiz_categories when a course is deleted.
Part of bug 2459
(http://moodle.org/bugs/bug.php?op=show&bugid=2459)
Merged from MOODLE_15_STABLE
Please check strings!! My English can be, sometimes, wrong!!! ;-)
I was using the $excluded parameter to avoid
loops between categories. A->B->A. Think we can
assume such loops won't exist, so I've deleted
the $excluded use.
Merged from MOODLE_15_STABLE
returns an ordered array of categories following
the parent-child relationships. It doesn't forget
any category and returns all the categories passed
although their parent were incorrect. Try to build
as much tree structure as possible.
Merged from MOODLE_15_STABLE
Fix for bug 3364:
The Great Global $course Hack strikes again. I had to put in another instance
of the hack for course themes to work in the "calendar" part of the course.
Hopefully some day we 'll do all that "correctly"! (search for "hack" in
weblib and despair).
More correct handling of group events, we cannot simply omit them because
the course has "no groups" UNLESS groupmodeforce == 1 as well.
Sadly, this severely weakens the performace optimizations :(
See bug 3303 for an example of what the problem was before.