Allow setting custom unit icons

[Agrendalath]

This allows setting custom icons for each unit in Studio. By default the icon will be derived from unit's type. The custom icon can be specified in studio - please see the screenshot.

JIRA tickets: OSPR-3059

Dependencies: None

Screenshots:

Testing instructions:

1. Check out this branch.
2. Log into the studio.
3. Create new course (or enter an existing one).
4. Create new subsection and couple of units inside it.
5. Click Configure (fa-gear) button next to the unit, choose custom icon from the dropdown (like on attached screenshot) and click Save.
6. Log into the LMS and enter modified course.
7. Enter the modified unit and check if its icon matches the chosen one.

Reviewers

• @kaizoku
• edX reviewer[s] TBD

[openedx-webhooks]

Thanks for the pull request, @Agrendalath! I've created OSPR-3059 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.

[edx-status-bot]

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

• jenkins/python
• jenkins/quality
• jenkins/bokchoy

[natabene]

@Agrendalath Thank you for your contribution. Please let me know once tests pass.

[natabene]

@marcotuts Do you think we should give this an early look?

[marcotuts]

From a product standpoint this isn’t something I would recommend enabling in studio. This is an example of something handled ideally as a plug-in but not in the core.

[openedx-webhooks]

@Agrendalath 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.

[Agrendalath]

@marcotuts, we are thinking about adding something like:

def  get_xblock_icon(xblock):
    return xblock.get_icon_class()

to XBlock to maintain compatibility with this part and to allow overriding icons with plugins.
Does this approach sound reasonable?

CC: @antoviaque

[antoviaque]

@marcotuts @nasthagiri @Agrendalath I haven't looked into the details here, but before rejecting a contribution to move it to a plugin, can we make sure there is a proper API in place to allow to support the feature?

To keep things sustainable on our end too, we need to make sure that we don't end up developing features in plugins that end up break during release upgrades - which will happen if we have to use or overwrite internal core methods to develop the plugin. If we can keep the PR open until we are clear on the API calls that can be used to maintain forward compatibility, that would help ensuring we don't end up without a good solution to achieve that.

(And to be clear, we can contribute those APIs as needed - we mainly need to agree on what they should be.)

CC @bradenmacdonald

[antoviaque]

CC @johnmark @feanil too since this is related to our conversation at the conference ^

[marcotuts]

@antoviaque - Happy to chat about how to advance the API discussions, this is something the team will be looking at in a dedicated way soon! (cc'ed @nasthagiri for visibility) In the interim, I do no believe it is valuable to keep this open though we can use this example potentially to talk through API requirements and needs in the future. fyi @johnmark , @feanil

[antoviaque]

@marcotuts OK thanks for the answer!

In the meantime, how do we address @Agrendalath 's needs here? How can he get an answer on his question, to be able to complete the development he is working on, before the project ends?

[antoviaque]

NB: See also a related situation in https://github.com/edx/edx-platform/pull/16669#issuecomment-483055730

[Agrendalath]

@marcotuts, are there any updates on this?

[Agrendalath]

@marcotuts, are there any updates on this?

[natabene]

@Agrendalath I will check and let you know if I learn anything.

[Agrendalath]

Great, thank you @natabene!

[wittjeff]

In cms/templates/js/icon-editor.underscore:
For accessibility, the icon dropdown needs a label that is semantically connected to the control. Please add:

• id="icon-label" to the h3 above the select.
• aria-labelledby="icon-label" to the select.

[marcotuts]

I don’t know that I can provide any more specific feedback on the approach toward maintaining compatibility. We are looking to build a new micro front end for the course experience, which would hopefully make this contribution easier to envision as a plugin in that application. This doesn’t help with a specific API / approach though, at least not initially.

I know @nasthagiri and others are putting time into distinctions within the world of APIs and how they would function. I don’t think we are in a place to specifically address this contribution’s needs though.

If there’s anything else you feel blocked by wrt to this PR let us know. Thanks!

[antoviaque]

@marcotuts

I know @nasthagiri and others are putting time into distinctions within the world of APIs and how they would function. I don’t think we are in a place to specifically address this contribution’s needs though.

What's missing to be able to address it? It's a useful use case, because it's a concrete need, and we can help with any work related to it.