openedx / openedx/openedx-platform

Support Unicode block codes

Open
#38,413 5 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

Dominant language
Python
Stars
8.2k
Forks
4.4k
Avg merge
6d 18h
Merged PRs (30d)
42

Description

Background

Block codes (aka slugs, aka block_ids, aka url_names, aka component_codes or container_codes) have historically been restricted to ascii slug characters (A-Za-z0-9_-). But, we recently discovered that we have some partial support for non-ascii characters in block codes in V2 content libraries: https://github.com/openedx/openedx-platform/pull/38402#discussion_r3121151211. Specifically, non-ascii alphanumeric unicode characters, i.e. the character class accepted by re.match(r'\w', unicode=True) in Python: https://docs.python.org/3/library/re.html**

Currently, as far as we know, you can only get a block with a non-ascii code by doing one of the following:

  • Creating a container (unit, subsection, section) with an initial title that includes non-ascii characters (in a content library)
  • Editing a component or container's key with the library backup ZIP, and then restoring that backup.
  • Creating a component or container with a non-ascii alphanumeric character (e.g., "θ") in the title and then copy-pasting that component into a content library. The original item won't have a non-ascii code, but the pasted item will.

In the long term we'd like to support such non-ascii codes, but in the short term we're concerned about downstream effects of those codes making into systems which were designed without unicode in mind, like:

  • modulestore
  • courseware student module
  • analytics

Acceptance criteria

  • Research the effect of non-ascii alphanumeric chars on those downstream systems
  • Decide which systems we feel are safe for such characters
  • Document this decision
  • Loosen UX-level validation as to allow for them
  • Do the same for: library codes, course codes, org codes. Or create ticket(s) for them.

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by tracing how non-ASCII block codes reach modulestore, the courseware student module, analytics, and UX-level validation. Research the same behavior for library, course, and organization codes, then document which systems are safe and identify the validation changes or follow-up tickets needed.

Written by the indexing model from the issue text.

Assessment

Tech stack
python
Domain
backend
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
42/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.