Instantiating new service in XBlock runtimes - issues or concerns?

Development
1

Hi all,

Our team has been making some improvements to PII sharing in our LTI consumer implementation. In our LTI consumer implementation, we have a CourseAllowPIISharingInLTIFlag ConfigurationModel, which stores whether PII sharing is enabled for a given course. In the XBlock, we must read from this model to determine whether PII can be shared in a given course.

We read from this model by defining an instance of the ConfigurationService in the StudioEditModuleRuntime runtime here. However, this is in the StudioEditModuleRuntime and enables us to read from the model only from the XBlock edit menu (i.e. the studio_view method). The improvements we are making require us to access to the ConfigurationService from other contexts - the author_view and the student_view methods of the XBlock.

However, the ConfigurationService is not defined in those runtime contexts. I believe that this is because the service instantiation is missing from those runtimes, here and here. Is that correct? Am I missing anything?

Is there anything I should be aware of before adding this service in these places? I do not understand the XBlock runtime well enough to know the potential repercussions or concerns with adding this service to these runtimes.

Please let me know. Thank you!

1 Like
2

@kmccormick I’m tagging you here, as you requested in Slack!

3

Hey @mroytmanedx . I did some digging and found this comment on the ConfigurationService, which points to a Jira ticket which links to a PR with an interesting discussion about the history of Configuration Service.

This comment from Nimisha looks helpful:

You don’t need to do anything further other than have the LTI xblock import django settings. You can have it conditionally import the settings (with a try-catch around it like here) if we are concerned about it being used outside of django. I would rather you make that change than to add LTI dependency in this xblock runtime.

So, it sounds like ConfigurationService was a temporary fix, and the longer-term solution was to (1) move the configuration models to xblock-lti-consumer and then (2) get rid of the ConfigurationService in favor of referencing the models directly from xblock-lti-consumer. The overarching goal seems to be that it’s better to tie XBlocks to Django than it is to tie edx-platform to particular XBlocks.

It looks like step 1 happened but step 2 didn’t. Do you think following through on step 2 would unblock the improvements you’re going for?