We had a few problems here.
1/ The auto complete element was displaying the picker though the
field was frozen.
2/ Checking for existing enrolment including the courses chosen was
not checking if the courses found were in the instance we edit.
3/ Upon creation we support multiple courses but when editing we
should not expect more than the course in the instance being edited.
This is a fix for a regressions introduced by MDL-54778. It
seems that escaped all our tests because there isn't any case
of such a dependency in core, but Daniele Cordella was facing
it within his surveypro module.
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.
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.
Andrew Nicols