You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In edx-platform, which accounts for virtually all of real-life xblock usage, a block's def_id and usage_id are assumed to be instance of opaque key classes.. This is helpful and lets assume other things too. For example, every XBlock usage in edx-platform will have an associated UsageKey, which, in turn, will have an associated LearningContextKey.
This XBlock repo, though, doesn't make that assumption. As of right now, xblock-sdk, the only other known XBlock Runtime, uses strings for scope IDs. We would like to update both this repo as well as xblock-sdk to use opaque key objects. Discussion: #690 (comment)
Just need to investigate the type of user_id a bit more. I know it can be None sometimes when an XBlock is not "bound" to a particular user. And at least in the "new runtime", an anonymous user gets a string ID. So I think it should be typed as int|str|None.
Activity
kdmccormick commentedon Jan 12, 2024
@bradenmacdonald , Here's the current ScopeIds definition:
I'm thinking we could change it to something like:
do you agree?
bradenmacdonald commentedon Jan 12, 2024
This is great, @kdmccormick
Just need to investigate the type of
user_ida bit more. I know it can beNonesometimes when an XBlock is not "bound" to a particular user. And at least in the "new runtime", an anonymous user gets a string ID. So I think it should be typed asint|str|None.Example: https://github.com/openedx/edx-platform/blob/2cd1410d9951f0b5cd1639f25dd34e191d4d75f3/openedx/core/djangoapps/xblock/runtime/runtime.py#L110-L117
feat: XBlock.usage_key, XBlock.context_key convenience props
feat: XBlock.usage_key, XBlock.context_key convenience props
feat: XBlock.usage_key, XBlock.context_key convenience props
feat: XBlock.usage_key, XBlock.context_key convenience props (#690)
kdmccormick commentedon Jan 31, 2024
I'm currently doing this in tandem with #707 , implemented by #713.
My thinking is that we'll make the change, bump the major version of XBlock, and pin xblock-sdk to an older version of XBlock.
Following up, we should either deprecate xblock-sdk, or a find a maintainer for it who is willing to remove the XBlock version pin.
feat!: Assume that scope IDs are opaque key objects (WIP)
kdmccormick commentedon Feb 14, 2025
Moving discussion/tracking to the relevant DEPR ticket...
feat!: Assume that scope IDs are opaque key objects