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
Use the current filters and sorting on the user grading table in the single
page grading app when it is possible.
This replaces the popover used to configure the filters to one that closely matches the
one from the grading table. It supports standard filters, workflow filters and allocated marker filters.
It will also support group filtering and suspended user filtering but we don't show the controls for those in
the single grading page.
The item field is defined as PARAM_TEXT (no HTML tags allowed except
for multilang).
Using the s that add quotes to HTML characters we avoid potential Web
Services invalid parameters errors.
The ‘description’ field is populated via a get_string call, this means
that it may content html.
The component used for translation is also fixed in this commit.
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.
If the grader does not have the accessallgroups capability,
or groups mode is set to separate groups and the user is not
a member of the group then no participants are shown.
Until now in the get_assignments WS all the settings for assignment
plugins (submission and feedback) are returned, this was bad because:
- It was returning settings for plugins that may not be enabled
- It was returning settings that would be a security risk (a third
party plugin including a password or credentials for connecting a
remote site)
- Some values was returned "raw" without further processing, for
example, maxsubmissionsizebytes returned 0 when using the plugin
default value instead a valid size
- Assignment plugins implemented an API for communication with the
external API, see for example: get_external_parameters, it didn’t make
sense had an API for the received parameters and not the returned data.
This commit reduces boilerplate code.
It also forces WS returning files to always return the following
fields: filename, filepath, mimetype, filesize, timemodified and
fileurl.
Mod assign list_participants webservice is supposed to accept a param to limit the
returned data to only show user ids and not the full user details. It is missing
and so the full user records are fetched every time. This has a major impact on the
performance of the new assignment grading interface.
