Now that PHP has support for named parameters, and we can use them in
Moodle, we should ditch `$options` arrays and use first-class,
documented, parameters.
Whilst this may seem scary, dumb, overwhelming, please note that you do
not need to supply all args, for example, to change the last parameter
of `format_text` you no longer need to do this:
return \core\container::get(\core\formatting::class)->format_text(
$text,
FORMAT_MOODLE,
$context,
false,
null,
true,
true,
true,
false,
false,
true,
);
Instead you can do:
return \core\container::get(\core\formatting::class)->format_text(
$text,
FORMAT_MOODLE,
$context,
allowid: true,
);
Or better still:
return \core\container::get(\core\formatting::class)->format_text(
text: $text,
format: FORMAT_MOODLE,
context: $context,
allowid: true,
);
This means that we can get defaults in the function signature, improves
our typing, and allows for deprecation and changes to options. It also
sets us up for success in the future.
If a student hides the timer, store that setting in their user
preferences in order to keep it hidden even if they go from one page
to another in a quiz.
* Fix the selector used to identify the preview icon element;
* Remove redundant code for handling it's click event, because it
already registers itself with a popup action which handles that.
The UX team proposal is to display two different notifications, to avoid confusion:
1. When the user is in preview mode:
Message: 'You are in preview mode.'
Notification Type: Information (blue), with the information permanently visible and not dismissible,
ensuring continuous awareness.
2. When activity tracking is disabled:
Message: 'Attempt tracking is not enabled for this activity. You can enable it in Settings.'
Notification Type: Warning (yellow) with a close icon for dismissal if tracking is intentionally disabled.
These notifications should only be visible to teachers and content creators, not students.
If a teacher also has a student role, this information should not appear when logged in as a student.
That's why the pre-existing is_tracking_enabled() function has been updated to only check if tracking
is on for an activity, without considering user capabilities (that's why the $user parameter has been
removed from this function too). Besides, a new function called can_submit() has been created to find
out if users are allowed to submit an activity.
