Creates a new capability mod/assign:viewownsubmissionsummary which will
be required in order to display the submission summary to the user in
the assignment page.
AMOS BEGIN
CPY [relativedatessubmissionduedateafter,mod_assign],[relativedatessubmissionduedateafter,core_course]
CPY [relativedatessubmissionduedatebefore,mod_assign],[relativedatessubmissionduedatebefore,core_course]
AMOS END
Before this change a teacher would be able to see users listed if:
* They have an active enrolment and can submit
* They have an an inactive enrolment for a role that can submit
After this change they will additonally be able to see users listed:
* That have an active enrolment and have submitted
* That have an inactive enrolment and have submitted
This means that if an assignment has it's context frozen all users
that have made some form of submission will still be listed.
It will also apply if the submission capability is removed from a
user.
If a user's enrolment is deleted they will not be listed.
The submission and grading counts have also been updated so
they will reflect the new rules.
Before this change if a student visited an assignment that is
frozen they would only see the title and description even if
they had made a submission to it.
After the change they will be able to see the status of their
submission and any feedback and grades they have recived.
It will also make the Moodle app recognise that submission
should not happen because the assignment is frozen.
Tests based on ones created by Andrew Nicols
This class would belong more appropriately within the 'user' API
(core_user) instead of within the 'core' API, since it is
directly related to user data.
Since the class has only just been added to Moodle, now is a good
time to move it.
The link to the calendar page is missing in the navigation block in
classic which causes a behat failure in the 'Set availibility dates
for an assignment' feature. The fix includes adding the calendar block
to the Course page which can be used to navigate to the calendar page.
I've gone over a few of the mofified files (those
which were showing warnings and errors to CiBoT. Some of them
have been fixed completely, while others only have fixed
for the lines belonging to this issue (lib/tests/moodlelib_test.php)
for example.
The methods assertContains() and assertNotContains() now perform
strict (type and value) comparison, pretty much like assertSame()
does.
A couple of new assertContainsEquals() and assertNotContainsEquals()
methods have been created to provide old (non-strict) behavior, pretty
much like assertEquals() do.
Apart from replacing the calls needing a relaxed comparison to those
new methods, there are also a couple of alternative, about how to
fix this, depending of every case:
- If the test is making any array_values() conversion, then it's better
to remove that conversion and use assertArrayHasKey(), that is not
strict.
- Sometimes if may be also possible to, simply, cast the expectation
to the exact type coming in the array. I've not applied this technique
to any of the cases in core.
Link: https://github.com/sebastianbergmann/phpunit/issues/3426
In PHPUnit 9.1, the following regexp-related assertions
have been deprecated and there are new alternatives for
all them:
- assertRegExp() -> assertMatchesRegularExpression()
- assertNotRegExp() -> assertDoesNotMatchRegularExpression()
This is about to, simply, move all cases to the new alternatives.
Source: https://github.com/sebastianbergmann/phpunit/blob/9.1.0/ChangeLog-9.1.md
Regexp to find all them:
ag 'assertRegExp|assertNotRegExp' -li
In all cases changes have been kept to a minimum while not making
the code completely horrible. For example, there are many instances
where it would probably be better to rewrite a query entirely, but
I have not done that (in order to reduce the risk of changes).
