@const is not a valid phpdoc tag and @var should be used to
document both classes properties and constants (no matter how
weird that may sound, heh).
Link to (draft right now) PHP-FIG:
https://github.com/php-fig/fig-standards/blob/master/proposed/phpdoc-tags.md#518-var
So, with this commit we are just replacing all uses by the correct
@var one. Note that the type is entirely optional, in fact I think
that there isn't much need of it for constants because it's obvious
for both humans and machines which the type is. But, as far as it's
also correct to specify it, we haven't modified that detail.
The only detail modified are the cases where the constant name was
specified in the phpdoc, that's not needed, hence, the names have
been removed from there when present (a couple of cases).
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
In these cases, mod_assign was treating other unrelated objects as its
personal object store. These have been updated to not require this.
Import now checks whether assignment is an group submission and
matches group ids instead of user ids in that case.
Additionally check for original unchanged files to not import in
group files instead of user files.
Converting these tests to use an onlinetext submission and drop the JS
requirement means that they are much less susceptible to runtime issues,
and not susceptible to those caused by JS at all.
This random failure was happening because of the time required to render
and interact with the file picker which sometimes exceeded 2 seconds,
depending on the speed of the machine running the tests.
Converting these tests to use an onlinetext submission and drop the JS
requirement means that they are much less susceptible to runtime issues,
and not susceptible to those caused by JS at all.
This commit does few things:
* Unify data generators usage to role short name.
* Replace remaining manual steps to use the new data generator.
* Also replaced other manual steps to set config to use data generators.
* Tidy up of some tests, aligning pipes and splitting one line steps into multiple lines.
* Fixes tests to have one Given/When/Then per scenario.
This feature had lots of small issues and it made sense to fix it whilst
investigating a query:
* most of the steps do not require JavaScript
* it uses the UI to set an admin setting, for every scenario:
** only 3-4 of the scenarios actually test that setting
** it is very slow to do it his way when we have a generator step we can use
* we create two assignments in the Background, but each test only uses one of them
* we create the assignments in the Background with a generator, but
update them to modify various settings in each Scenario using the UI
when we should just create one assignment for each test and set it up
correctly for that Scenario
MDL-45580 introduced the readonlypages filearea, and when loading
page images for an attempt, the code would check if the pages existed
, creating them if not. The code inside this block also contained
a guard clause for the case where no readonly pages existed - which
is a situation that should not happen. Whenever readonly pages are
requested, they should exist.
MDL-66626 introduced a situation where page counts not matching would
also retrigger page generation. However this led to a situation where
the guard clause could be entered when requesting readonly pages.
This patch refactors the guard clause, and improves the logic to
regenerate pages.
When requesting the readonly version of pages (which contain
teacher annotations), they should always be available - the
PHP side even throws an exception when they're not. This
means we don't need to worry about polling document converters
from the JS side and can just return the pages immediately.
The behat step "I draw on the pdf" creates the exact same line every
time it is called. This can cause issues in a situation like the following:
- Student uploads PDF
- Teacher annotates page 1
- Student edits submission, adding another PDF
- Teacher annotates page 1 again
- When the student looks at their annotated PDF it appears the same as
before they added the second PDF (i.e., they don't see extra pages for
the second PDF)
Exactly why this happens isn't clear, and in practice this probably never
happens because the chances of drawing the exact same line twice are almost
0. However, when testing the functionality added in MDL-45580 it was causing
issues.
