For consistency I renamed the old check_examples_assessed function to
check_examples_assessed_before_submission.
I also call the new function in the existing
get_workshop_access_information external function.
Increase the scope of the files that are detected and
indexed by Moodle's Global Search. This includes intro
and content areas of search areas. The use case here is
in a description for an activity there is a file added
that contains more information about the activity.
It would an advantage to be able to search this content
as well. It would also allow search engine plugins to be
able to index non text files such as images.
This was done for indicators, targets and time splitting methods so that we
can get the string identifier and component in order to display a help_icon.
The functions were also made abstract, removing the default implementation.
Indicators, targets and time splitting methods should define this function.
It was decided to roll only configuration dates and any date related to user content
such as 'timecreated' , 'timemodified' etc should not be rolled forward.
The completion set_module_viewed and the course_module_viewed event
code has been moved to the workshop class.
This change is consistent with other modules (like lesson, feedback or
quiz) and it is necessary to be able to use the new method via WS.
Now that the validation is provided directly by the filemanager, we do
not need to do the same here.
Note that existing Behat tests are left untouched to make sure there is
no regression.
It turned out that behat's "I should see ..." does not work for buttons
rendered as `<input>` elements so this assertion worked only in Boost
where the button is rendered as `<button>` but not in Clean.
But we do not really need this check here. All we need is to make sure
that the form has been saved successfully. For which, checking for the
text on the page is enough.
p.s. Another mistake of mine to not double-check behat on both standard
themes. Sigh ...
This Behat scenario was not failing only because it actually relied on
the bug in the wrongly set accepted_types for submission attachments.
Now that the previous commit has fixed that bug, this scenario started
to fail correctly.
We need to do the same trick here as we are doing in the latter
scenario: we first upload a valid file to bypass the upload repository
checks, and rename it before submitting the form. That allows us to see
that the invalid file is caught finally.
p.s. It was a silly mistake of mine. I should had been wondering why
the same procedure worked for one field and not for the other. I would
spot the bug with wrong accepted_types earlier.
It was a copy&paste mistake that the accepted_types option for the
submission attachments used the value configured for overall feedback
attachments.
Credit goes to Marina Glancy for catching this during testing.
Juan Leyva