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.
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.
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.
Although the screenshots in the failures for some of the scenarios in
filter/displayh5p/tests/behat/h5p_filter.feature, like "Render a local
H5P file as teacher" were displaying the expected result, there were
some javascript errors (probably due to behat is quicker and the
iframes were not always ready).
I've added one extra step before accessing the iframe to give more
time to the H5P player to load and confirm the page is displayed
properly.
* The object returned by update_question is alwasy a new clone
and the $question passed in will not be modified.
* The returned object has the fields like questionbankentryid and
the ones related to versionning, so it is more like the data
returned by question_bank::load_question_data.
The used the exist in Moodle up to 3.11, but then was removed with
insufficient thought in 4.0 (because we had grander long-term plans
which still have not happened). Until those plans happen, this
commit adds the simple link back on the preview screen.
