The new form elements were not including the markup for advanced
and required fields. I used an <abbr> tag in the label to give
and accessible indication of the advanced and required fields.
Part of MDL-55071
This change allows form elements to be overridden with a mustache template.
The template can even listen for form validation errors and supply the JS to
change the look of the form element when there is/isn't a validation error.
Initial support is for all core form elements including:
text, select, selectyesno and checkboxes, groups, dateselector, datetimeselector,
autocomplete, modvisible, advcheckbox, button, duration, filemanager, filepicker, editor, static, grading,
warning, textarea, password, url, submit, questioncategory, recaptcha.
Part of MDL-55071
When a field is disabled in the page - no value is sent and modgrade is reverting
to the default. This change prevents the max grade from changing accidentally.
Instead of using the more rollup-tolerant config for all files, make the
configuration stricter by default but lower in grunt for yui modules.
This means that manual runs (prechecker) or editor integrations will
flag up the errors as well as grunt.
Also add ignore lines to the core files so that eslint isn't noisy when
not running with grunt.
The changes in this commit should not be problematic, just:
- different whitespace.
- some docs.
- 1 variable to camelCase.
And then, less trivial, but safe enough IMO:
- a change to camelCase some identifiers and their calculation.
The original issue here was that each loop of the named values did not
check for prototypal properties. As a result, if there were input fields
with names such as 'sort', 'valueOf', 'constructor', etc. these would
return their prototypal functions instead of a falsy value, and be treated
as though they are array - hence the 'Cannot push to Function' type error.
Following on from this I discovered that the data stores were being created
as arrays, but used as objects. This can also cause issues with some form
input names -- e.g. if they are numeric.
These two issues were resolved together by correctly storing them in
objects, and checking that those objects had real properties
(hasOwnProperty). This itself has to use the prototypal function to cater
for the potential of a field name called 'hasOwnProperty'.
I also found that the instance value stores were being initialised in the
prototype (and therefore shared), which meant that there were numerous
issues if two forms were present on the same page, or one form replaced an
existing one (e.g. forms initialised in JS).
In addition, it also became apparant that several values were being used
outside of scope, or in the wrong scope. This caused further issues when
creating multiple forms on a page.
This was affecting both to rateable (forum...) and not rateable
(assignment...) activities. So tests have been completed to verify
that now saving is performed and the correct scale values stored.
Changing the error message that is displayed to users when they
upload a file that is greater than the maximum upload size. Does not
include all upload cases; focuses on those most used by students.
This is a squashed commit containing a number of changes:
This is an ajax driven course selector that has searching etc. It can select single, or multiple courses.
Make course selector accept a list of courses to exclude
courseselector - lookup coursename on setValue
Use the get_course_display_name_in_list function to generate the course names
Add a throttle to auto-complete to reduce spamming the server
Do a single query to fetch all the courses in the mform element when validation fails
Fix core course search function to return results when there are less than 2 chars in the query.
Handle setData with an empty array in new course selector
If mod has grades, then while upgrading
modgrade_type is disabled. This will not post
it with form and hence validation fails.
To avoid above problem, use ->currentgradetype
if modgrade_type is not set
Three additional checks have been added.
Once grades have been recorded for the activity/grade item -
1) Do not allow the grade type to be changed.
2) Do not allow the scale to be changed.
3) If we are using ratings do not allow the 'Maximum points'
value to be changed.
Also reordered form elements, removed form elements that
were not necessary, added and changed existing language
strings to improve the overall UI.
The previous method of generating the id attribute of the elements
within the modgrade group did not take the name of the modgrade field
into account. So if there were multiple fields of the modgrade type
added into a form (not a common case yet still valid), elements created
within the group were assigned same id attributes.
The patch introduces a new method for generating the id attribute of
modgrade elements. The new method takes the name of the modgrade group
into account and returns the id in the format similar to the default one
returned by HTML_QuickForm_element::_generateId().
The patch changes the generated id attribute. Apart from the
block_activity_results' behat feature files, not other places seem to
rely on the exact value.
