Files
edx-platform/requirements
michaelroytman 85207225fc fix: hidden lti_version and 1.3 fields in edit view and incorrect menu behavior in Javascript
This commit updates the version of the lti-consumer-xblock from 4.3.0 to 4.3.1. This installs the newest version of the lti-consumer-xblock library. This version includes the following changes.

This commit fixes three bugs.

1. The first bug is that the lti_version field is inappropriately hidden in the Studio author view edit menu when the selected config_type is database.

2. The second bug is that the editable_fields property of the LtiConsumerXBlock is inappropriately excluding LTI 1.3 fields when the config_type is database. The editable_fields property should include LTI 1.3 fields even when the config_type is database, because the Javascript defined in xblock_studio_view.js may want to show these fields if the user selects a different config_type in the menu. We want to support a dynamic edit menu, so these fields must be considered editable by the XBlock in order for the Javascript to be able to manipulate them.

3. The third bug is in inconsistent rendering of the Studio author view edit menu. Depending on the order in which a user selects lti_version, config_type, or lti_1p3_tool_key_mode, different sets of fields are displayed, due to the overlapping sets of rules that govern what fields should be hidden or shown for a given field selection. This commit corrects this inconsistent rendering by first showing all fields and then gradually hiding fields depending on the sets of rules, for each change to the fields.
2022-07-22 10:19:27 -04:00
..
2018-04-13 14:10:40 -04:00
2022-05-24 15:15:00 +05:00

Requirements/dependencies
=========================

These directories specify the Python (and system) dependencies for the LMS and Studio.

- ``edx`` contains the normal Python requirements files
- ``edx-sandbox`` contains the requirements files for Codejail
- ``constraints.txt`` is shared between the two

(In a normal `OEP-18`_-compliant repository, the ``*.in`` and ``*.txt`` files would be
directly in the requirements directory.)

.. _OEP-18: https://github.com/edx/open-edx-proposals/blob/master/oeps/oep-0018-bp-python-dependencies.rst

Upgrading/downgrading just one dependency
-----------------------------------------

Want to upgrade just *one* dependency without pulling in other upgrades? Here's how:

1. Change your dependency to a minimum-version constraint, e.g. ``my-dep>=1.2.3`` (or update the constraint if it already exists)
2. Run ``make compile-requirements`` to recompute dependencies with this new constraint

If you instead need to surgically *downgrade* a dependency, perhaps in order to revert a change which broke things:

1. Add an exact-match or max-version constraint to ``constraints.txt`` with a comment explaining why (and ideally a ticket or issue link)
2. Lower the minimum-version constraint, if it exists

    - Not sure if there is one? Try going on to the next step and seeing if it complains!

3. Run ``make compile-requirements``

This is considerably safer than trying to manually edit the ``*.txt`` files, which can easily result in incompatible dependency versions.