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).
pdftoppm (from poppler-utils package) is several orders of
magnitude quicker than ghostscript extracting PNG images
from PDF documents.
We add support for this tool and use it whenever set up,
or using gs as before if missing.
Revisited code with peer review comments. In particular:
1. Make default path for pdftoppm empty string.
2. Fix a typo on the method description for get_gs_command_for_image.
3. Added more information why is useful pdftoppm into string pathtopdftoppm_help.
4. Check that path for pdftoppm is executable to prevent errors. Otherwise, use gs.
Save comment in the assignment when the Save changes
or Save and show next button are clicked at the bottom
of the page.
Signed-off-by: Sujith Haridasan <sujith@moodle.com>
These steps were creating content manually in an unnecessary fashion. I
had to debug some issues with features in these areas so took the time
to update them to make use of data generators, which are significantly
faster.
This just deletes all the upgrade steps previous to 3.6.0. Some
small adjustments, like tweaking globals can also be applied
when needed.
Also includes an upgrade step to prevent upgrading from any
version < 2018120300 (v3.6.0) as anti-cheating measure.
Note that in this case, there wasn't any case of upgradelib
functions being used, hence we haven't to deprecate/remove
anything in codebase. When there is such a need, that is done
in separate commits (one for each function) and documented here.
See MDL-65809 commits for an example removing/deprecating a
good number of functions.
Behat does not play well with confirmation dialogues and in some
situations it does not wait for the page to reload before starting the
next step.
This change adds a pending_js call which is only resolved if the cancel
button was pressed, otherwise it remains in-progress until the page
reloads resetting the entire state of it.
