When marking workflow is enabled, students will be notified only when
the workflow state transitions to 'Released'. Until that happens,
sending of messages will be held and the 'Notify students' grading
form option will be locked.
Additionally, the batch set marking workflow state facility gains
the 'Notify students' option.
Credit to Steve Upton and David Balch for the basis of this patch.
This fixes the recent activity callbacks to ignore submissions with a 'new' status.
The unit tests for recent activity were modified, because they were relying on the old behaviour of 'submitted' being the default status.
AMOS BEGIN
CPY [submissionstatus_,mod_assign],[submissionstatus_new,mod_assign]
AMOS END
* 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.
Updated code to restrict list of users. Also includes changes to
ensure that a cm_info object is available (required for availability
checks).
There is a tweak to upgradelib to reflect the different fields used.
(Note that upgradelib is not used during upgrade, but only when
converting assignments from the old assignment module.)
MDL-45965 assign: add notification capability
Adds a new capability that adds flexibility to what users receive grader
submission messages. Includes phpunit tests. Function is based off of
get_graders() but is separate because it is bad form to have a
capability that is dependent on another capabilities setting.
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.
Having a I click on we can use all our selectors rather
than having multiple steps for the same purpose. This
step allow us to manage JS native dialogues without
having to fail a scenario.
Credit for Mohamed Alsharaf.
The behat script is to test the batch action to lock and unlock submissions.
The new definitions are to prevent the "unexpected alert open" error in Selenium.
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.
