Item Delete -- Card State Propagation

Status: Requested Repository: operations Related: Item Delete Bug #782

Context

Bug #782 identified a specific failure mode: when an item has multiple supplies, a PROPAGATE update creates a forked bitemporal version chain, which permanently blocks the item from being deleted. The immediate fix (in progress) adds updateSupplyOnly() to prevent the fork from being created on future updates.

A separate broader question was identified: when an item is deleted, what should happen to its associated Kanban cards?

The Question

Deleting an item that has active cards (cards in REQUESTED, INPROCESS, or other non-AVAILABLE states) creates an inconsistency: the cards reference an item that no longer exists. The behavior in this case is not defined.

Options Under Consideration

1. Block delete if active cards exist — return an error if any associated card is not in AVAILABLE or CANCELLED state. Safest, but requires the user to cancel or complete cards before deleting an item.

2. Cascade cancel cards on delete — when an item is deleted, automatically move all its cards to CANCELLED state. Clean, but may surprise users.

3. Soft-delete only — mark the item as administratively disabled rather than deleting it. Cards can continue to reference it; the item no longer appears in active lists.

4. No restriction — delete the item regardless of card state. Cards retain their last-known item reference data.

Status

This question was identified as out of scope for the Bug #782 fix. It is captured here as a requested backlog item for a future design decision.

Prerequisites

• Bug #782 fix should be complete before this is addressed, as the fork issue may affect how card-item relationships are traversed.