On Exiting scrom activity, it goes back to course
and scrolls to section. On slow machines next step
fails. To avoid such case navigate to home screen
and then follow next step.
In the recent issue MDL-56225, we started to record the current user as
the usermodified in the forum_discussions table when updating a forum
post. It made sense but it was a mistake.
Even if the current user really modifies the discussion by updating the
post, the field usermodified has actually been always interpreted and
displayed as the last post' author. Not as the last user who touched the
discussion.
This patch reverts that particular change to the previous behaviour and
adds explicit unit test for it.
Fixes bug where the resource module loads metadata for all files while
building course modinfo, even though it only needs the first file.
(This causes problems if you have ~10k files.)
Previously there was a logic bug where by if some students were filtered
from the list, the label for another student could be attached to the
'filered' student.
This fix reworks the promises a bit so we render the student summary and
then build an row with the explict user id, rather than itterating through
the array later.
I also remove the storing of the initial promise in a varible because
this is an easy way to introduce a bug (not waiting for the .then()
chained promise)
The PARAM_TEXT has been misused in certain cases here. The 'action'
parameter seems to always be alphabetic, with values like
savesubmission, editsubmission and others as handled in assign::view().
Fixing the action handling fixes the reported XSS issue. While working
on it, I spotted two more places where PARAM_TEXT does not seem
appropriate. I include changes for them too, even if they are no
strictly related to the reported bug and there are no known ways to
abuse it.
* The 'plugin' looks like PARAM_PLUGIN and is even declared as such in
some other parts of the assignment code (such as feedback forms).
* The 'workflowstate' is one of the ASSIGN_MARKING_WORKFLOW_STATE
constants and is supposed to be alpha in external function input
parameters handling, too.
The 'attachments' is not a real DB field here. It comes from the form's
filepicker and holds the id of the attachments filearea. The function
forum_add_attachment() expects it as a property of the first argument.
There were two possible approaches here. Either to pass the raw $newpost
to forum_add_attachment(), or add the attachments into the list
modifiable fields. The second approach is safer.
