Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

[Out of scope - UXD] Show competency-status impact in delete and archive confirmations

Đang mở
  • Có gì không ổn?
#787 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 1 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
5/5
Thời gian dự kiến
Hơn một tuần
Mức phù hợp với người mới
20/100
Loại issue
Tính năng
Độ rõ ràng
Cần làm rõ
Mức độ hoạt động
Sôi nổi
Công nghệ
django, python
Lĩnh vực
backend, backend-api-design, databases

Hướng nghiên cứu

Không có tệp triển khai hoặc bài kiểm thử nào được nêu tên. Hãy bắt đầu bằng việc xem xét phương pháp đã được phê duyệt trong #655, các thiết kế xác nhận trong 10.2 và các bảng trạng thái learner từ #642; kiểm tra các điểm truy cập của Tag, Taxonomy, CompetencyCriteria, CompetencyCriteriaGroup và ObjectTag. Trước khi viết mã, hãy giải quyết các câu hỏi còn bỏ ngỏ về thiết kế và hiệu năng, sau đó xác định các bài kiểm thử chấp nhận cho những learner bị ảnh hưởng riêng biệt và các xác nhận không có tác động.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

Out of scope. Recorded so the idea is not lost, not scheduled for build. Product asked for this to be documented as a future nice-to-have rather than built as part of the guardrails work.

User Story

As a course author or platform administrator, I want a delete confirmation to tell me how many learners have already earned mastery through the thing I am about to remove, in order to judge how consequential the action is before I take it.

Acceptance Criteria

Scenario: A confirmation reports how many learners are affected
  Given a record that learners have earned competency mastery through
  When the author is shown the confirmation for deleting it
  Then the confirmation reports how many learners have mastery recorded through it

Scenario: A confirmation reports when nobody is affected
  Given a record no learner has been evaluated against
  When the author is shown the confirmation for deleting it
  Then the confirmation says that no learner mastery is affected

Scenario: The count does not slow the confirmation down noticeably
  Given a record used across a large number of learners
  When the confirmation is opened
  Then the count is shown without a noticeable delay

Description

The guardrails work gives every delete a confirmation whose wording is deliberately the same whether the record will be removed or retired, and which says nothing about how many learners are involved. That is a conscious simplification: it keeps the author from having to understand the archive mechanism, and it keeps the confirmation from needing a count that is expensive to compute.

The cost is that an author gets no sense of scale. Removing an association nobody has been evaluated through and removing one that hundreds of learners have earned mastery through look identical.

This placeholder covers extending the confirmations to report that impact, for Tag, Taxonomy, CompetencyCriteria, CompetencyCriteriaGroup, and ObjectTag deletes.

Technical Details

This section is background and a suggested approach, not the ticket's source of truth. The User Story and Acceptance Criteria define what must be true when the work is done.

In short

Why this was deferred rather than included. The count is not a field that can be read; it is an aggregate over learner status rows reached through the criteria that reference the record. Doing it for one record on demand is affordable. Doing it for every row of a list, so an author sees impact before opening a dialog, is the expensive version, and the guardrails work chose not to take that on while the delete branch itself was still being built.

The cheap version and the expensive version are different tickets. Computing the count when a single confirmation opens is one query for one record. Showing it against every row in a list is an aggregate across the whole page and needs its own design. This placeholder is the first; the second would be a further ticket if anyone asks for it.

It needs the guardrails work finished first. The deletion lock records that a record is depended upon but not by how much, so a count means traversing to the learner status rows. That traversal only exists once the competency status tables and the criteria models are in place.

Implementation specifics
  • Scope is five record types: Tag, Taxonomy, CompetencyCriteria, CompetencyCriteriaGroup, and ObjectTag.
  • Count distinct learners, not status rows. A learner with mastery recorded at several levels through the same record is one affected learner, and "3 learners" is meaningful to an author where "7 status rows" is not.
  • Compute on demand when the confirmation opens, as one aggregate query per record, rather than precomputing or denormalizing a counter. Nothing else needs the number.
  • The wording is a design question, not just a number. Whatever the count is, the message still has to avoid implying that those learners will lose their mastery, since they will not. This needs a design pass before it is built.
  • Out of scope even within this placeholder: showing impact against every row of a list rather than in a single confirmation, and any change to what a delete actually does.
  • Context The approved implementation approach on #655, which settles that the confirmations do not report impact in the initial work.
  • 10.2 designs the confirmations this would extend; 10.12 and 10.13 implement them.
  • #642 provides the learner status tables any count would aggregate over.

Open Questions

  • Is a count the right thing to show, or would a plain "learners have earned mastery through this" with no number serve the same purpose more cheaply and age better? Owner: BA, with the designer.
  • Should the impact be shown for a Taxonomy delete, where the number could be very large and the aggregate correspondingly expensive? Owner: architect.
Ngôn ngữ chính
Python
Star
10
Fork
33
Merge trung bình
2 ngày 23 giờ
Pull request đã merge (30 ngày)
21

Chuẩn bị môi trường

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của openedx/openedx-core

Tất cả issue của openedx/openedx-core

Issue tương tự

Thêm issue về Python

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.