Until now in the get_assignments WS all the settings for assignment
plugins (submission and feedback) are returned, this was bad because:
- It was returning settings for plugins that may not be enabled
- It was returning settings that would be a security risk (a third
party plugin including a password or credentials for connecting a
remote site)
- Some values was returned "raw" without further processing, for
example, maxsubmissionsizebytes returned 0 when using the plugin
default value instead a valid size
- Assignment plugins implemented an API for communication with the
external API, see for example: get_external_parameters, it didn’t make
sense had an API for the received parameters and not the returned data.
This commit reduces boilerplate code.
It also forces WS returning files to always return the following
fields: filename, filepath, mimetype, filesize, timemodified and
fileurl.
1. getMock()
2. setExpectedException()
3. checkForUnintentionallyCoveredCode renamed to beStrictAboutCoversAnnotation
4. beStrictAboutTestSize renamed to enforceTimeLimit
5. UnitTestCase class is now fully removed.
Mod assign list_participants webservice is supposed to accept a param to limit the
returned data to only show user ids and not the full user details. It is missing
and so the full user records are fetched every time. This has a major impact on the
performance of the new assignment grading interface.
Without this change, the unit tests make assumptions for the output of
mod_assign functions/webservices that do not hold true when 3rd party
submission and feedback plugins are installed.
* Remove hardcoded table names
* Remove some code that was left in after debugging
* Add some comments about grades with no submission
* Set submission->latest to 0 on restore (it will get fixed later)
* Changed get_records_sql to get_recordset_sql in restore.
When different ID's are set for each sequence a number
of unit test failures appear. They have been corrected
to allow unit tests to pass with the new generator in place.
The changes performed with the change from
create_from_user() to create_from_submission()
in practice enforce a new restriction about
submissions having to exist in order to fire
their lock/unlock events.
This did not exist before the change and, also,
it seems that the assign api itself, submission->lock() ...
also accepts non existing submissions.
So I was not 100% sure about how to fix these events:
1) enforcing submission to exist.
2) firing them only if the submission exist.
I've gone with 1) for now, making tests to pass. But will
raise the question in the Tracker, just in case we have
to move to the 2) approach for any reason.
Andrew Nicols