Specifically in the case where multiple content items are returned, and
when we hit the content_item_to_form() method, ensure that content-item-
specific values do not influence the final value of launchcontainer,
which must use the value set in tool configuration.
These settings are no longer configurable on a per-instance basis, so
'delegate to teacher' needs to be removed from the options list for the
relevant fields in the tool type edit form. For existing tool types,
allow 'delegate to teacher' to continue to be used only if it's the
currently set value of these fields. If changed, it cannot be set again.
This form layout applies when adding or editing any instance which is
based on a preconfigured tool (course or site). That is now the only
supported way of configuring a mod_lti instance.
Move all the logic dealing with display of the legacy instance form,
(which displays those frozen, manually-configured instances) into a
method of its own for clarity.
The absence of SVG files has been addressed by including them,
sourced from the respective FontAwesome versions available for
download at https://fontawesome.com/icons
MDL-78806 core: Remove redundant site name on page titles
* With the site name now being appended to the page titles, there
is no need to manually append the page titles.
The following were added in MDL-69489 and had a few issues, which are
fixed in this patch:
Unit tests:
- were not using the existing generator.
- were making assertions inside a foreach, which doesn't test anything
if the result set returned is empty (error prone).
- were calling setAdminUser() unnecessarily.
Behat tests:
- the restricttocategory.feature file used manual steps to setup site
tools.
This is already supported in lti_add_type, via the lti_coursecategories
config value, so all that's needed is to match the categories by
idnumber and pass through the resulting ids.
This adds a single scenario covering all the expected behavior for those
existing, manually configured tools. It also removes any tests dealing
with creation of manually configured instances, which is not supported
any more.
This replaces the legacy scenario, which used the '+' on the activity
instance edit form, with a scenario covering the cartridge use on the
new course tools (LTI External tools) edit form.
This change:
- removes all uses of mod/lti:addmanualinstance and deprecates it.
- updates the activity instance edit form, specifically the way it deals
with existing manually-configured instances, removing the ability to
edit tool configuration and adding a notice to the user.
This method includes broken legacy behaviour in which the inclusion of
course and site tools could be controlled independently, based on the
capabilities 'mod/lti:addmanualinstance' (to include course tools) and
'mod/lti:addpreconfiguredinstance' (to include site tools). This
behaviour is deprecated in 4.3, so this method is also deprecated. See
the replacement method types_helper::get_lti_types_by_course.
Users without the 'mod/lti:addpreconfiguredinstance' capability won't be
able to see any mod_lti content items in the activity chooser.
Note: this patch doesn't address the underlying locallib method,
lti_get_lti_types_by_course(), which will be addressed elsewhere.
This change ensures tool instances which are currently using
preconfigured tools (site or course level) are not able to be switched
back to use the manual 'Automatic, based on tool URL' option. That
option is reserved for legacy tool support of manual instances and
domain-matched site tools, but must not be selectable otherwise.
In summary:
- Remove the 'External tool' item from get_course_content_items()
hook, which results in its removal from the activity chooser.
- Remove the 'External tool' item from get_all_content_items() hook,
which results in its removal from the admin activity chooser
recommendations page.
- Prevent use of the edit_form for creation of new manual instances.
- Retain the ability to edit existing manual instances.
- Fix tests expecting external tool.
This allows behat tests which have already created either a site or
course tool type, to then link it to an activity instance using a
generator. This depends on the ability to name match a type.
This method is used by behat only, where only a single arg is received.
The method lti_add_type() expects two params: type and config, but will
only ever receive one. This means not all the fields can be set when
creating an lti type. This change:
- Removes the superfluous param which the method won't receive
- Improves the logic for handling type and type config data, making it
match what happens when creating types via mforms.
- Adds relative URL support to the baseurl field, allowing behat
features to create types using local tool fixtures.
- Sets sensible default for missing config data, allowing the created
tool type to be used in launches in places like behat.
This method is used by behat only, where only a single arg is received.
The method lti_add_type() expects two params: type and config, but will
only ever receive one. This means not all the fields can be set when
creating an lti type. This change:
- Removes the superfluous param which the method won't receive
- Improves the logic for handling type and type config data, making it
match what happens when creating types via mforms.
- Adds relative URL support to the baseurl field, allowing behat
features to create types using local tool fixtures.
- Sets sensible default for missing config data, allowing the created
tool type to be used in launches in places like behat.
This change removes the 'Tool configuration usage' control for course
tools being edited via site admin. All course tools are, at a minimum,
considered to be preconfigured tools and are visible in the course.
The visibility of course tools in the activity chooser will be
controlled via the LTI External tools course page in future.
This will only impact newly created course tools, not existing tools.
Existing tools will be listed in the LTI External tools page and
teachers will be able to add them to the activity chooser from there.
This was hitting the lti_types table twice, via both lti_get_type and
lti_get_type_type_config. This change adds course to the stdClass
returned by the latter, so we can just make a single call to that.
This also permits the use of that course property in other places
where we'd like to have access to it, such as when editing a pre-
configured tool at site level.
* Add new table for LTI types course categories
* Update LTI add / update form to restrict tool availablily in selected course categories
* Bumped version
