Add location ID to Studio component footers

[stvstnfrd]

This is helpful for a number of use cases for us at Stanford,
where instructors/staff/admin need access to an item's location id.

Previously, we'd have to dig this value out by other means.
This makes it easy to discover and use as needed, eg: copy/paste, etc.

One major example of our use of it is with the in-video-quiz XBlock [1][2],
which maps video components to capa problems.

• [1] https://github.com/Stanford-Online/xblock-in-video-quiz
• [2] https://github.com/Stanford-Online/xblock-in-video-quiz/blob/master/invideoquiz/invideoquiz.py#L41-L61

[openedx-webhooks]

Thanks for the pull request, @stvstnfrd! I've created OSPR-3428 to keep track of it in JIRA. JIRA is a place for product owners to prioritize feature reviews by the engineering development teams.

Feel free to add as much of the following information to the ticket:

• supporting documentation
• edx-code email threads
• timeline information ("this must be merged by XX date", and why that is)
• partner information ("this is a course on edx.org")
• any other information that can help Product understand the context for the PR

All technical communication about the code itself will still be done via the GitHub pull request interface. As a reminder, our process documentation is here.

[stvstnfrd]

[stvstnfrd]

CC: @mondiaz @jen-nifer
in case I'm missing other major use-cases worth highlighting.

FWIW: We've been running this on our instance for years now,
finally getting around to submitting it upstream ;)

[natabene]

@stvstnfrd Thank you for your contribution. @marcotuts can you give this your blessing before this goes to engineering?

[edx-status-bot]

Your PR has finished running tests. The following contexts failed:

• jenkins/bokchoy

[marcotuts]

Hi Steve thanks for submitting this. I don’t believe this is something we would want to show in components in Studio even though it streamlines certain use cases such as the in-video quiz.

I’d sooner want to explore ways to make the authoring for this component easier than expose this ID on all components.

I’m marking this closed for now. In the future when we get to revamp Studio this is the kind of thing I’d expect would be an easy plugging to see in the authoring experience.

[openedx-webhooks]

@stvstnfrd Even though your pull request wasn’t merged, please take a moment to answer a two question survey so we can improve your experience in the future.

[mondiaz]

Other use cases:

1. This feature came as a pleasant surprise to a faculty member I met with last month who wanted to look up people's submissions to a handful of questions in one unit.

• Being able to copy and paste the problem location IDs from the Studio view of the unit saved her from having to click on "Staff Debug Info" for each problem on the page in the LMS view, which in turn made the task less tedious and saved her time. She was very grateful that our instance offered that option. She could in turn then paste those into the field above the "Download a CSV of problem responses" and click the button to generate that report. Still a lot of steps, but if she has 5 problems in that unit, then that's 4 extra clicks we've spared her. And those add up.

2. Another course team uses conditionals, so this implementation of ours saves them some time, since with conditionals, you need one component ID for if someone answers the problem right ("show this component at location X") and a different one if they answer it wrong ("show this other component at location Y"). Same benefit as Put back in the blocks for Advanced Settings. #1 where having the component location IDs available in Studio makes it easier to copy and paste multiple component location IDs in fewer clicks.

[jen-nifer]

@marcotuts I'd like to reiterate how exposing the information has been helpful to course teams and that in absence of easier authoring, it eases the authoring process. Is there data available showing how often component IDs are viewed that can also be another data point?

[natabene]

@marcotuts Do you have any insight on the above mentioned?

[marcotuts]

The next time we sync I'd love to discuss additional ways we can still support the authoring goals / improvements described above. I think each of these is connected to another workflow improvement / simplification that I think will help. We can at that time discuss how to balance the concern of exposing this string / text visibly on the components and see if there is another way to accomplish this goal.