In getValidationScript function variable $element can be an array or object.
Function attempt get non-existing attributes.
To avoid this we should check before accessing.

If suite is not default then add suite name
to end of faildump file name

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.

noreplyaddress should be a valid address, else
it will not be saved. For behat we don't send
email, so set it to noreply@example.com, to
avoid failing validation on localhost

It was discovered by unit tests that the return value is not a real
boolean as was intuitively expected and documented. To avoid potential
issues with the truthyness in the future, we explicitly cast the return
value to boolean now.

The patch adds validation for the noreplyaddress setting variable, for
the explicit $replyto parameter and for the sender's email. In case of
misconfigured noreplyaddress setting, it falls back to the default
noreply address value. In case of invalid email in the user's record,
the email is not sent.

The patch also adds unit test for the value returned by the function
generate_email_processing_address() so that it can be considered as a
valid email, too.

This is supposed to significantly minimise the risk of exploiting the
vulnerability in PHPMailer's Sender field.

The noreply and support emails should always be valid.

David Mudrák authored Jan 04, 2017 and Dan Poltawski committed Jan 04, 2017

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.

Ankit Agarwal authored Dec 08, 2016 and Dan Poltawski committed Jan 04, 2017

We allow only .scss files so allow files to be included only and only if they end in .scss and they exist on server under theme directory.

Sometimes db doesn't return records in order
So enusre it is in order so that last record
doesn't have section equal 0. As section 0
can't be deleted.