Some templates can legitimately contain invalid HTML (e.g. mismatched tags)
because the templates operate in pairs.
In these instances we should not use an editor because the nature of the
editor (content editable) means that the browser automatically corrects all
HTML supplied to it, thus breaking the template entirely.
Therefore we need to disable HTML editors for some templates, and do so in
a way tied to the instance of the activity, rather than to a specific user.
This patch adds a new 'config' field, with matching setters and getters, to
allow such per-instance values to be stored.
New function data_user_can_manage_entry checks whether a user is allowed to manage an entry.
Considering manageentries capability, data_in_readonly_period() result,
ownership (determined by data_isowner()), approval and manageapproved setting.
version = planned 2015051100 release version
requires= current 2015050500 rc1 version
Note: On purpose, the course format social wrong version (2015102100)
has been kept unmodified. Looking forward a solution right now.
Fix accidental <tr> in some field modify screens
Update mod_data version
Change required asterisk to image
Improve required error message
Fix required icon positions
Remove required code from date field
Add name in labels for fields
Add required field option for multimenu
Remove old required field title text modifier
Add multimenu to behat
Add more comprehensive behat tests
Reload old input when an input error occurs
Behat grammar fixes
Allow location of 0, 0
Use html_writer
Fix existing mod_data behat tests
This is implemented for most fields but not all. The reason is that there are
some fields for which this does not make sense because no entry is a valid entry.
The supported fields are:
checkbox
file
latlong
menu
number
picture
radio
text
textarea
url
The unsupported fields are:
date
multimenu
* 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.
Andrew Nicols