From f642a75ae0df4731d05861111f9cc15e735ccd69 Mon Sep 17 00:00:00 2001
From: Giovanni Cimolin da Silva <giovannicimolin@gmail.com>
Date: Wed, 17 Nov 2021 14:53:47 -0300
Subject: [PATCH] docs: Pluggable/reusable LTI configuration
---
.../0006-pluggable-lti-configuration.rst | 117 ++++++++++++++++++
1 file changed, 117 insertions(+)
create mode 100644 docs/decisions/0006-pluggable-lti-configuration.rst
diff --git a/docs/decisions/0006-pluggable-lti-configuration.rst b/docs/decisions/0006-pluggable-lti-configuration.rst
new file mode 100644
index 0000000..a241ae1
--- /dev/null
+++ b/docs/decisions/0006-pluggable-lti-configuration.rst
@@ -0,0 +1,117 @@
+Pluggable and re-usable LTI configuration
+-----------------------------------------
+
+
+Status
+======
+
+Proposal
+
+Context
+=======
+
+LTI Tools provide extra funcionality and allows course creators to embed external interactive content
+in the LMS through a standardized setup.
+
+Currently in the Open edX platform:
+
+* Each LTI tool needs to be configured individually, sometimes requiring multiple valiables to be set to get a working integration. This makes the course creation process cumbersome on courses that heavily rely on LTI components.
+* There's no support for instance-wide LTI tool configuration or any sort of pluggable LTI configurations.
+
+This proposal aims to solve these issues by introducing a mechanism to allow LTI configuration pluggability
+and changes to the XBlock to allow re-using configurations to reduce instructor friction.
+
+
+Decision
+========
+
+The decision is to enable LTI reusability and pluggability using a filter hook (as defined in `OEP-50`_) to fetch re-usable LTI configurations
+from external plugins.
+
+With this implementation the plugins are responsible for storing the LTI configuration and credentials, while the LTI consumer handles displaying the content.
+
+To enable this, the LTI Configuration model needs to be modified to:
+
+#. Allow externally configured tools (a new :code:`CONFIG_EXTERNAL` choice for the configuration storage).
+#. A new fields to store an namespaced tools id in the format (:code:`plugin_name:identifier`).
+#. Changes to the :code:`get_lti_consumer` methods to allow instancing a :code:`LtiConsumer` from externally managed configurations.
+
+The filter will allow the XBlock LTI Consumer to query re-usable and/or plugabble LTI configurations and display them to course
+creators as configuration options in Studio.
+The filter response should contain all the necessary information for the XBlock to locate and and use the externally managed LTI configuration.
+
+The inputs for the filter pipeline should be:
+
+* The course ID, so that each filter is able to evaluate and return only configurations available to that context.
+* A dictionary in which LTI configurations will be added/modified by each plugin.
+
+Filter responses are accumulative and receive the output of the previous function (`Filter tooling - pipeline behaviour`_),
+so the filters will initially recieve an empty dictionary and each filter will incrementally add its available configurations,
+using a namespaced key with the plugin name plus an internal identifier (Example: :code:`lti_plugin_1:random-identifier`).
+
+1. Initial state of filter input
+
+.. code-block:: json
+
+ {}
+
+
+2. After the first filter is run:
+
+.. code-block:: json
+
+ {
+ "lti_plugin_1:a-plugin-interal-indentifier": {
+ "lti_version": "LTI_1P1",
+ "lti_1p1_client_key": "LTI KEY",
+ "lti_1p1_client_secret": "LTI SECRET",
+ "launch_url": "https://saltire.lti.app/tool",
+ "tool_name": "Saltire LTI test tool",
+ },
+ "lti_plugin_1:another-indentifier": {
+ ...
+ }
+ }
+
+This filter has two purposes:
+
+#. Allow the XBlock LTI Consumer to display users a list of available re-usable configurations.
+#. Return LTI configuration data so that the LTI Consumer is able to spawn a `LtiConsumer` class.
+
+When an user launches a re-usable configuration, the LTI consumer model will run the filter pipeline, retrieve the credentials if they are available,
+instance the appropriate :code:`LtiConsumer` and return it to the XBlock for usage.
+
+Related feature flags
+=====================
+
+.. list-table::
+ :widths: auto
+ :header-rows: 1
+
+ * - Toggle name
+ - Type
+ - Behavior
+ * - LTI_ENABLE_REUSABLE_CONFIGURATIONS
+ - Feature flag
+ - This flag enables LTI Configuration reusability and will display an extra field during the LTI
+ configuration that will allow selection from pre-set configurations.
+
+
+Changes to the LTI Consumer XBlock
+==================================
+
+To allow re-usability, the XBlock will need the following changes:
+
+#. An extra configuration type will need to be added to the *LTI Version field*: :code:`Use predefined LTI configuration`
+#. When the option above is selected, a new field must be presented so that the user can pick one of the available re-usable configurations.
+#. The methods to retrieve the LTI consumer will need to be reworked to factor in re-usable configurations.
+#. Some LTI endpoints that are tied to the XBlock will need to be decoupled from the XBlock runtime urls to remove :code:`LocationKey` dependencies.
+
+
+Implementation concerns/Consequences
+====================================
+
+#. The `LtiConfiguration` model needs to be decoupled from XBlocks so that grades and student information don't get mixed between instances.
+
+.. _OEP-50: https://open-edx-proposals.readthedocs.io/en/latest/architectural-decisions/oep-0050-hooks-extension-framework.html
+.. _Filter tooling - pipeline behaviour: https://github.com/eduNEXT/openedx-filters/blob/main/docs/decisions/0003-hooks-filter-tooling-pipeline.rst
\ No newline at end of file
--
GitLab