The check is superfluous and uses an inexistant variable ($type) that
was removed when we switched to role based enrolment.
Fixes MDL-11098 MDL-10282 and MDL-8346.
The number of submissions in the Group average and Course average calculations
should be shown in brackets. (submissions) should be added after the Group average
and Course average labels.
Solution:
new grader report preference (Display number of grades in average cells).
Only students should appear in the tutor report, however
sorting by Surname results in the tutor being included, which we don't want.
Solution:
Confirmed as a bug and filed in tracker: http://tracker.moodle.org/browse/MDL-11233
Issue:
Clicking on Hide Groups reveals the results for all students
and all tutors and course staff appear. A tutor should only be able to see
the results for their tutor group
Solution:
Prevent tutors from ever seeing student grades from other groups: use existing capabilities
moodle/site:accessallgroups = off AND moodle/grade:viewall = on
Issue:
Preferences tab should not be available to users without gradereport/grader:manage capability
Solution:
Hide the tab completely
Issue:
Apply different style to average cells
Solution:
Add css classes to the different average cells, and write a default style in css file.
Issue:
The Average under group average might be better labelled Course average.
Solution:
Rename to "Complete average"
By moving the performance profile logging to the very
end of PHP processing, we cover more pages, notably those
that don't end up with a footer or a redirect, like file
serving.
This should improve quality of our performance logs, and
help catch some piggies...
rebuild_course_cache() over all courses is extremely expensive,
not suitable for interactive calling. Better to clear modinfo
and let course/view.php repopulate it as needed.
With this patch we clear out modinfo _only_ for courses affected
by the module we show/hide/delete.
Move the fixups for orphan courses to the newly minted
fix_coursecategory_orphans() -- and optimise it to take only 1 dbquery for
the common case.
If we do find lots of orphans, we issue 2 updates per orphan.
This cuts down dbqueries drastically - we used to have 2x the number of
courses in the site.
Two improvements for fix_course_sortorder()
- If the category has more courses than the shift range
use a larger shift range to avoid overlapping with itself
- If things do go wrong during the per-course sortorder updates,
rollback and try and call ourselves with a 'safe' flag.
Still - far from perfect. Probably the global sortorder approach
is broken. The sanest way is to rework things to always join against
course_categories and order by the combined sortorders.
