Expand flexibility of LTI configuration and visibility

[jpoulos]

Theme Overview

Admins spend a lot of time configuring LTI tools and are limited in their ability to set up, view, and customize them, often resulting in time spent removing and reinstalling.

What value could this provide to users?

• More UI options to configure or modify LTI tool configurations
  
• Greater flexibility in LTI tool configuration; specifically around tool visibility and access

Why was this theme chosen to open for voting?

April 2023 • As we continue to develop our LTI 1.3 solution, we want to ensure we’re meeting user needs and making installation and configuration as seamless as possible.

Why was this theme not chosen for prioritization?

June 2023 • We are prioritizing work on Dynamic Registration, which is a precursor to the LTI flexibility improvements. We will be creating a report which will enable administrators to find all enabled developer keys in a system as well as the permissions they have been granted (including for inherited keys.) Release notes on this will be coming soon. Although we’re not able to commit to the theme as a whole, as we have capacity we will do our best to make small improvements in this area, as we recognize it is important to our users.

[ProductPanda]

Note from Instructure

April 2023 • This theme was chosen to Open for Voting. 

How do Ideas and Themes work in the Instructure Community? 

How do I participate with themes? 

[IanGoh]

From having configured LTI at both root and sub-account levels, the challenge is remembering where all the LTI configurations are.  We use external documentation for the integrations, but it would be nice for root admins to be able to see what was configured, and where, without having to visit each sub-account.

[phanley]

Just checking - is enhancing the "install by client id" workflow (so that its changed to something like "install a configured app", i.e. a ui for picking an undeployed-in-the-cuerrent-context configured LTI key so the user doesn't have to a) go to the Developer Keys page to get the client id  if they're an admin or b) not even realize that there's a list of client ids that they could choose from because they. aren't an admin) included in this theme?

I'd love to see enhancements to the LTI Key UI in admin and other enhancements, but as more of our tools migrate to 1.3 enhancing the deployment step of LTIs becomes more desirable imo.

[JamesSekcienski]

@IanGoh I agree that managing the LTI configurations gets tricky when trying to limit access to a tool to select subaccounts/courses.  To build on what you said, rather than just being able to see what is configured and where, I would prefer to be able to install the apps at the root account level and then select which sub-accounts should have access to them, similar to what the person requested for the Chat app.  This way the app only needs to be installed once and then access can be limited to only select sub-accounts that should be using the tool.

[JamesSekcienski]

@phanley That sounds like an interesting idea.  It sounds like you are suggesting creating a selection similar to when you select the external tool for an assignment submission, but this would be to install the app to an account or course. It may be good to add on to this to include a setting with the Developer Key for whether or not it would be included as an option for individual course level installs in case admins only want the tool installed at account level or only installed in select courses, which would likely require the install by client ID option to still exist too.

I do think your idea would fall under this theme, but with this new process I'm not sure if it would be considered as part of this vote cycle if it isn't one of the referenced ideas.  If you haven't already I would recommend submitting it as an Idea too so it can be documented.

[JamesSekcienski]

These are some of my top requests related to this theme and the related ideas:

• The ability to edit/enter all LTI parameters in the Canvas UI when setting up Developer Keys
  • There are several settings for external tools that can only be configured by knowing the proper setting to use in the JSON configuration and/or by knowing the settings to update through an API call after installing the app.
  • This creates unnecessary extra steps when trying to deploy/update tools and increases risk of misconfigurations due to formatting errors. 
  • This also creates a barrier for schools/institutions where they may not have the expertise/confidence to make these changes via API or JSON.
  • One of the most common issues I have seen in the community is the need to prevent apps from being enabled by default in the course navigation.  While there are some community posts that share how you can use API calls to change this setting or modify the XML, it can still be concerning to some users to make these changes via these methods.  This is one example of a setting that would be highly beneficial to include a toggle for in the Developer Key configurations.
• The ability to disable tools to support transitioning/end-of-life for external tools
  • As pointed out in the related idea, it would help with being able to restore a tool if it was decided to use the tool again.
  • Similarly, it would also help if a tool was found to still be needed for a course that was undocumented and/or an unexpected issue was found when trying to upgrade an LTI and the old version still needed to be used.  Sometimes partners require the old version to be uninstalled for the new version to work, so it would be really problematic if the old version needed to be restored in this case.
  • In addition, when upgrading tools or transitioning to a new tool provider, there may be overlap during the transition period where the old tool still needs to be used in some courses while the new tool needs to be launched for new courses.
    • It would be useful to have a way to disable the old tool so it couldn't be used in new courses, but could still be used in old courses.
    • It would then also be useful to have it fully disabled even in old courses after the transition period is over.  Perhaps this could be controlled by a date with the disable setting or two different disabled states.
• Granularity of access for tools
  • It would be convenient if account admin could install an app at root and control which sub-accounts would have access to use it.
  • This was suggested for the Chat app, but I think it would be beneficial for all external tools.
  • Considering tools may be needed in multiple sub-accounts, but not all, rather than installing it in each sub-account it would be easier to install the tool once and configure it to only be available for use in select sub-accounts.
    • This would help centralize the tool installs and make it easier for account admins to manage without having to go to each sub-account.
    • It would also help declutter the list of external tools in courses (i.e. when using an external tool assignment) if the course is in a sub-account that shouldn't be using the tool.
    • This would also help if a tool is being tested/piloted for courses in a certain sub-account with plans to expand to additional sub-accounts in the future if everything goes well

[milesl]

@IanGoh I agree it would be helpful to have integrated tools to track where LTIs are installed, but I wanted to make sure you're aware of the LTI report, which is what I currently use for this purpose. You can filter the context to "account" and then see a list of all LTI installations in sub-accounts.

[IanGoh]

Thanks @milesl for pointing out the report!  Is there an easy way to tell which are LTI 1.1 vs 1.3?

tooltype name / launch url might hint (if they were nice enough), but typically not...

[phanley]

I thought I had added this previously, but piggy backing on @JamesSekcienski excellent list of QoL lifecycle improvements, under the "disable tools to support transitioning/end-of-life for external tools" section:

• a last_available_term_id and/or last_available_date fields where admins could specify term limits (ha ha) for tools, so that in courses set to terms with starting dates occurring after the starting date of last_available_term_id or that would still be running the tool would be unavailable, even if an instructor made the course months beforehand.
• and additional field end_of_life_date would be helpful in cases where there was a license that would expire or generate new expenses, this would be a hard cutoff date (as opposed to last_available, which would selectively disable a tool like James described
• an alternative disabled_launch_url would also be useful (especially if there was an option to launch) -- universities could set a link to a web page where the EOL was announced or documentation about new processes, and external vendors could use the launch when they need to update

[JamesSekcienski]

@IanGoh I don't think the report available in Canvas includes the version.  However, if you are comfortable with using the Canvas API to make reports, the External Tools includes the version information.

@phanley Those are good suggestions as well.  I especially like the disabled_launch_url as it would be useful to provide a clear message to users that the tool is no longer available to use and what alternatives are available (if any)

[ProductPanda]

  Comments from Instructure

June 2023 • This theme was not chosen for prioritization.

We are prioritizing work on Dynamic Registration, which is a precursor to the LTI flexibility improvements.

We will be creating a report which will enable administrators to find all enabled developer keys in a system as well as the permissions they have been granted (including for inherited keys.) Release notes on this will be coming soon. Although we’re not able to commit to the theme as a whole, as we have capacity we will do our best to make small improvements in this area, as we recognize it is important to our users.