BaseLMSCapabilities#

class BaseLMSCapabilities[source]#

This class defines the capabilities of an LMS connected using LTI 1.3.

An important note about naming in this class: most of the attribute names are not really intuitive. For example: supporting set_deadline means that we probably don’t get the deadline from the LMS. This has two main reasons: 1) legacy: these strange names mirror the names used in our LTI 1.1 classes, and 2) it describes what you can do inside CodeGrade with the LMS, maybe it is in the future possible to sync back the deadline to the LMS, and in this case the name set_deadline makes way more sense.

lms: str#: The name of the LMS.

set_deadline: bool#: Is it possible for users to set the deadline of a CodeGrade assignment within CodeGrade? This should be True if the LMS does not pass the deadline in the LTI launch, and False otherwise.

set_lock_date: bool#: Same as set_deadline but for the lock_date date.

set_state: bool#: Should the state of the assignment be set within CodeGrade and not be copied from the LMS? If False users are not allowed to change to state of the assignment within CodeGrade (they can always set the state to done).

set_available_at: bool#: Should the available_at of the assignment be set within CodeGrade and not be copied from the LMS?

set_name: bool#: Should the name of the assignment be set within CodeGrade and not copied from the LMS?

set_max_attempts: bool#: Are we allowed to set the max attempts within CodeGrade.

cookie_post_message: Optional[str]#: The name of the iframe postMessage we can send to the LMS to notify that we want to set cookies in a full window. This property is ugly, and shows that these capabilities are not really a very good abstraction: Only Canvas supports this, and it is not that likely that other LMSes will support this in the exact same way as Canvas does now. If set to None this LMS doesn’t have any post message that will allow us to send cookies (this is currently the case for all LMSes except Canvas).

supported_custom_replacement_groups: Sequence[Sequence[str]]#: A list of replacements groups (or namespaces) supported by this LMS. Some LMSes support more replacement variables than others, however we don’t want to send replacement variables to an LMS we know it will never support. This property contains a list of custom replacement groups supported by this LMS. For example: we have a replacement variable called ‘$com.custom_lms.User.name’, this variable will be included (parsed and returned as wanted config), if the supported_custom_replacement_groups contains [‘$com’]. It will also be included if it contains [‘$com’, ‘custom_lms’]. However, it will not be included if it only contains [‘$com.custom_lms’] or [‘$com’, ‘other_lms’].

use_id_in_urls: bool#: Should we use the LTI1p3Provider.id in the url. Some LMSes do not provide both the iss and the client_id in all launches. This means that finding the correct LTI1p3Provider is not always correct (especially as the iss often gets used multiple times). For some LMSes therefore it is a better idea to simply include the id of the provider in the launch url, and verify with the given information that the provider could theoretically be the correct one (i.e. all given information matches with the information in the LTI provider that belongs to the id).

actual_deep_linking_required: bool#: Does this LMS require actual deep linking, where the user inputs a name and deadline.

auth_audience_required: bool#: Is it required to set a separate OAuth2 Audience for this LMS before we can finalize it.