openedx / openedx/openedx-core
[Placeholder for UXD] Create UX Design for managing Competency Rule Profiles at Organization, Course, or Taxonomy levels.
Nobody has claimed this yet.
- Dominant language
- Python
- Stars
- 10
- Forks
- 32
- Avg merge
- 2d 17h
- Merged PRs (30d)
- 12
Description
Blocked on: Team discussion in this Slack thread, which raises open questions about the CompetencyRuleProfile data model and permission model — most relevant here: whether the taxonomy scope can be null (affecting how "system default" and org/course-only profiles are filtered and listed), whether a reverse lookup from a profile to the content it governs belongs on this endpoint or a separate one, and the platform-admin/org-staff read/write permission split. Also depends on https://github.com/openedx/openedx-core/issues/613 (CBE core data models) landing first. Write the full ticket immediately after these are resolved and documented.
Use Case
As an instance administrator, I want a clear UX for creating, editing, and viewing a Competency Rule Profile at the organization, course, or taxonomy level, so that I can define reusable rule defaults once instead of duplicating rule configuration on every criterion, and so anyone authoring criteria can tell at a glance which level's rule actually applies.
Description
Current state: No CompetencyRuleProfile UI exists. The model is defined only in proposal-status ADRs as "a reusable rule definition (rule type plus payload) scoped to an org/course/taxonomy, so criteria can share a profile and override it when needed." This is greenfield: no backend API, no authoring surface, nothing to reference visually.
Requested change: produce UX design artifacts for the three CRUD-ish flows (create, edit, view) of a rule profile at each of the three scope levels, plus a way to show the fallback/precedence order when levels overlap. Out of scope: any backend or frontend implementation, profile versioning, and delete.
Acceptance Criteria
This is a design spike. The deliverable is design artifacts and documented decisions, not working code. There is no Gherkin and no QA path.
- Figma flow: create a rule profile at org, course, and taxonomy scope
- Figma flow: edit and view an existing profile at each scope
- Wireframe/annotation showing how precedence is surfaced when an org, course, and taxonomy profile could all apply to the same criterion
- Each Open Question below resolved and documented with rationale
- Handoff notes for the dependent frontend implementation ticket
Open Questions
- [BLOCKING] Who can manage a profile at each level — instance admin only, or can course authors manage course-level profiles? (Determines permission-gating in the design.) Options: A) admin-only at all levels, B) admin for org/taxonomy, course author for course-level. Recommended: B, matches the existing taxonomy admin/course-author read-only split noted in cbe-project-context.md.
- [non-blocking] Does "managing" include delete, or is this create/edit/view only for now? Recommended: create/edit/view only; deleting a profile that criteria already reference likely needs its own confirmation-flow ticket.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Research direction
Start by reviewing the linked Slack discussion, issue #613, the proposal-status ADRs, and cbe-project-context.md. Resolve and document the data-model and permission questions before creating the full ticket. Done means Figma flows for create, edit, and view at all three scopes, a precedence wireframe, rationale for decisions, and frontend handoff notes.
Written by the indexing model from the issue text.
Assessment
- Domain
- design
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Quiet
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100