* Added the component and ratingarea fields and implemented it throughout
the rating API as mandatory fields
* Cleanup rating indexes
* Upgrade forum/data/glossary ratings
* Moved the logic in the render_rating method to methods of the rating object.
* Added new callback for checking ratingareas
* Cleaned comments here and there
* Mark the xxx_get_participants methods as deprecated
* Refactor rate_ajax and ratingsuser_can_view_aggregate methods
* Cleaned up rating/index.php to use html_table object and moved inline styles to CSS.
* Added missing properties of the rating object that were being set throughout the rating
API.
Rather than performing complicated upgrade procedures from the old (broken) logic in three activity modules, we are adding new capabilities to those three modules to make them all consistent, and using them in a callback from the Ratings API. This is the same as the Comments API.
The downside is that two sets of capabilities need to be enabled for ratings to work. Hopefully this can be mitigated somewhat when build some sort of shortcuts on the module settings forms to set capabilities. In the meantime, the effect is reduced somewhat by having all the rating capabilities enabled by default for student and teacher roles. This means control is in the hands of whatever the modules have set, giving very close backward compatibility.
This is not the perfect solution, but neither were the other two.
=======================================
WARNING: DEV IS CURRENTLY VERY UNSTABLE.
This is a mega-checkin of the new Roles system. A lot of changes have
been made in core and modules.
Currently there are a lot of rough edges and known problems. We are
working hard on these .. .the reason for getting this into HEAD at this
stage is enable us to move faster (our branch was diverging from HEAD
too much).
Please keep an eye on http://docs.moodle.org/en/Roles for current status
and information for developers on how to use the new Roles system.
block is constructed. A new function exists to pump these notes out
in a standard way : print_recent_activity_note.
Module dependencies also updated because of this.
(While I was at it I also turned the autologinguests off for most module pages, except on the index.php pages and the view.php pages for those modules that allow guests)
Now, print view is different for each format (consistent with it).
New, custom formats can, optionally, define their print view. Else
the default one will be used.
With this, 1.4.x glossary developments are finished and we can start
solving some pending things in 1.5...
Merged from MOODLE_14_STABLE
Decide if an entry is editable:
-It isn't a imported entry (so nobody can edit a imported (from secondary to main) entry)) and
-The user is teacher or he is a student with time permissions (edit period or editalways defined).
Bug 1445
(http://moodle.org/bugs/bug.php?op=show&bugid=1445)
See the TODO.txt to get details about pending tasks.
The db upgrade should work fine (not tested under postgresql).
The plugin architecture is finished too.
See Bug 936.
(http://moodle.org/bugs/bug.php?op=show&bugid=936)
