The $CFG->svgicons setting was introduced in Moodle 2.4 due to incomplete
SVG support in certain web browsers.
The landscape has evolved significantly since then, and all modern browsers
now handle SVG files correctly.
The $CFG->svgicons settings has been removed and the supports_svg() method
has been updated with currently supported browsers (IE support was removed
in Moodle 3.10).
This covers the case where a course is published and the launch data
doesn't include the 'lineitem' property of the ags claim, meaning the
tool can manage its own line items.
This handles things like site policies, which store the current URL,
redirect to the policy agreement, then redirect back the current URL
afterwards. In such cases, we want to redirect back with 'launchid' set
so that we can fetch the id_token from the session cache. This is the
same thing we already do during account binding, so the patch only
makes sure the PAGE->url is properly set before calling require_login.
If an activity, like workshop or forum, has multiple grade items,
declarative binding of the grade item (line item) isn't supported.
Instead of throwing an exception, handle the case more elegantly
and just omit the 'add to gradebook' option for these activities.
Only call user_update_user when the relevant user data has changed,
preventing unnecessary user_updated events. This also removes the
line setting timemodified on the user since user_update_user already
handles this.
In PHP 8.2 and later, setting a value to an undeclared class property is
deprecated and emits a deprecation notice.
So we need to add missing class properties that still need to be declared.
If the enrolment instance (the 'published resource') has been upgraded
from LTI 1.1/2.0 to LTI 1.3 (i.e. a new instance was not created),
prevent legacy launches which may occur from old resource links. Only
LTI Advantage launches should be permitted through the method.
If the enrolment method is updated from an LTI 1.1/2.0 tool to an LTI
1.3 tool, it may have associated enrol_lti_users records not having
ltideploymentid values. These are legacy users and must not be returned
by the repository, which deals only with LTI 1.3 LTI users.
As in MDL-74691, we need either or both of these fields, meaning either
one could be omitted. This just supports that as per the fix made in
MDL-74691.
This covers the following cases:
1. Where only the 'lineitem' service endpoint is provided
2. Where only the 'lineitems' service endpoint is provided.
Existing tests already cover the case where both are provided.
If member sync runs before the user launches the tool, a partial record
is created, without consumer secret. Subsequent launches of the tool by
that member don't resolve this and this results in grade sync failing
for any affected users. This patch:
- data fixes the existing affected rows
- fixes the launch code, ensuring secret is recorded on launch,
irrespective of whether the user info record has been created already
or not.
Fixes the enrol_lti_users.consumersecret field for LTI 2.0 users.
This field erroneously contained the tool secret and not the consumer
secret needed for service requests when used with LTI 2.0 consumers,
which resulted in complete grade sync failure for LTI 2.0 consumers.
This patch:
- adds an upgrade step to address existing incorrect secrets for LTI
2.0 launched users. It sets these to the correct consumer secret.
- fixes the way the secret is first set during a launch, ensuring
this->consumer->secret is used, which properly captures either the
tool secret (for 1.1 launches) or the consumer secret (for 2.0
launches).
The lib/lti1p3 library now passes $options['form_params'] instead of
$options['body'] when making access token requests. To maintain the
'application/x-www-form-urlencoded' content-type required by OAuth 2.0
(https://www.rfc-editor.org/rfc/rfc6749#section-4.1.3), the client has
been changed to convert these array params into a body query string,
which matches the behaviour prior to the library upgrade and makes
the tool can continue to call tool platform services. Support for
$options['body'] remains, as this is still used during service calls.
