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

[thelmick-unicon]

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 [Arch] Implementation approach for competency data delete/edit guardrails #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.
• Mastery status lookup + learner progress models #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.