Skip to content

Kanban Card Updates

In MVP2, without explicit Loop entities, KanbanCard entities are created with a direct reference to an Item
and they denormalize some information from Items that may change over time. Additionally for the use cases that the system needs to support in MVP2, mostly dealing with Procurement workflows, whenever an Item is created, one Card should be created to minimize the user friction to start using the system.

As of Q4-2025, any Items created from the Arda User interface have a KanbanCard automatically created by the UI itself. Bulk upload of items though does not have this capability and there is a ticket to implement it: Bulk import creates items that don’t have a card

The Kanban Card Service need to subscribe to Item Change events and react to keep consistency with the item updates:

Kanban Card Information Dependencies

uml diagram

Propagation Rules

Item Create

When a new Item is created, a new KanbanCard should be created referring to the new Item with the following
initial values

  • serialNumber: Unique
  • item An object with the item eId and name
  • cardQuantity The item’s minQty
  • locator: The item’s locator
  • lastEvent: null
  • status: KanbanCardStatus.AVAILABLE
  • lastPrintEvent: null
  • printStatus: KanbanCardPrintStatus.NOT_PRINTED
  • notes: Either the Item cardDefaultNotes or notes properties.

Item Update

When an Item is updated, all cards that refer to it (through their item.eId property) should be updated to reflect the changes in the item. Each property is updated iff it is either null or the value of the corresponding initialization property in the previous version of the item. Otherwise, the property value is kept as it reflects a direct external update to the card.

The values in the item object should never be updated directly in the Kanban Card. Out of the eId and the name, only the name is editable in the Item, so the item.name is always updated to the most current version of the Item.

Item Delete

When an Item is deleted, Kanban Cards that refer to it should:

  1. Pin their references to the Item to the Deletion Record of the Item.
  2. Marked as DISABLED and
  3. Prevented from being updated.

It is still TBD at this time (Q1-2026) what other restrictions on the behavior of the card should be imposed. Display, Printing and inspection of the card should clearly indicate the card is DISABLED.

The DISABLED state comes from the concept of Resouce with its OperationalState.


Copyright: © Arda Systems 2025-2026, All rights reserved

Comments