Includes multiple changes to the shifter task to simplify and
support this:
* Use grunt.file for shifter yui 'module' detection rather than our own
70 line function
* Use grunt.util.spawn rather than our own exec for shifter
* Improve behaviour on various yui subdirectories
We have to add the 'async' depndency to npm because we are running
multiple async operations in the single task. We use async.eachSeries to
run each shifter job sequentally (else the output would be unreadable
when running async).
We also run shifter in non-recursive mode on the module directory so its
not building everything (thanks to Ryan for pointing this out!)
We mess around with the cwd to find a shifter path, not ideal but avoids
having to refactor the shifter task.
Also fix jshint errors..
1) The gruntfile runs in a nodejs environment and not a browser
environment.
2) There was an uninitialised variable
This is in preperation for the watch task and doing a few things:
1) Switch away from 'grunt.file.expandMapping' to the declarative syntax
for doing the same thing, as recommended in docs:
http://gruntjs.com/api/grunt.file#grunt.file.expandmapping
2) Factor the renaming function into shared function so it can be used
from the watch task too.
3) Shared the file glob'ing pattern for match AMD js files between
jshint and uglify task (this removes the node_modules exception..
we should add it to both if we need it).
4) Rename the task configuration - I am just doing this because it looks
like 'dynamic_mappings' is some how magic config option when you
look at the manual:
http://gruntjs.com/configuring-tasks#building-the-files-object-dynamically
But in fact, it's just a task confguration name.
I noticed we do not need to list the names of potentially affected
reviewers. If the user (teacher) has the capability to see other
assessments (which they do in 99%), the list of assessments is displayed
at the confirmation page anyway. If for some reason they do not have the
capability, we should not list the names.
The second fix is that the action buttons (such as Delete or Edit) are
not displayed on the removal confirmation page.
And finally, as the output->confirm() wraps the message with implicit
<p>, it is not valid to pass HTML with any block elements. So instead of
concatenating the two messages, we simply define a new string for this
situation.
A new capability is introduced to control this, granted to teacher/admin
roles by default: mod/workshop:deletesubmissions. Additionally, students
can delete their own submissions if they are currently able to edit them.
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.
Two reasons for this change:
1) The configuration here is confusing, it seems like we are setting the
'files' option, but in fact we are just generating a task configuration
called 'files'. Lets try and avoid confusion.
2) It makes it possible for 'watch' to override the src
