Hacktoberfest 2026: los issues que los mantenedores marcaron para octubre, abiertos y aptos para principiantes. Explorar issues de Hacktoberfest

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

Abierto
  • ¿Algo no está bien?
#787 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 1 día

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
5/5
Tiempo estimado
Más de una semana
Aptitud para principiantes
20/100
Tipo de issue
Nueva funcionalidad
Claridad
Necesita aclaración
Estado de actividad
Activo
Stack tecnológico
django, python
Área
backend, backend-api-design, databases

Línea de trabajo

No se nombran archivos de implementación ni pruebas. Empieza revisando el enfoque aprobado en #655, los diseños de confirmación en 10.2 y las tablas de estado de los Learner de #642; inspecciona los puntos de entrada de Tag, Taxonomy, CompetencyCriteria, CompetencyCriteriaGroup y ObjectTag. Antes de programar, resuelve las preguntas abiertas de diseño y rendimiento y, después, define pruebas de aceptación para Learner afectados distintos y confirmaciones sin impacto.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

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.
Lenguaje dominante
Python
Estrellas
10
Forks
33
Merge medio
3 d 2 h
PR fusionados (30 d)
20

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de openedx/openedx-core

Todos los issues de openedx/openedx-core

Issues similares

Más issues de Python

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.