Not able to drop calendar cards to the column which sits just above the columns having cards.

[git-init-priyanshu]

Bug Description

In the month calendar, a card cannot be dropped onto a day column that sits directly above a day column containing cards. Even when you hover over the day column you want, the drop target still points to the day column containing cards.

Example:

720p.mov

Expected behavior

The drop target should point to the day column you are hovering over, even when it sits directly above a day column containing cards.

Technical inputs

This happens because the sortable cards (DragDropItemSortableCell) have a collisionPriority of 3, while the day column has a lower collisionPriority of 1. So when you drag a card over the day column above, the card's collision wins.

We never pass a collisionDetector to useSortable for the cards, so they use defaultCollisionDetection. That detector runs pointerIntersection first and falls back to shapeIntersection, which matches on rectangle overlap instead of pointer position. The dragged card still overlaps the cards below, so that fallback makes the drop target land in the day column containing cards.

[git-init-priyanshu]

I would like to work on this. Thanks.

[twenty-eng-sync]

Kind: Probably a real bug. Month-calendar cards can resolve to a populated day below the day currently under the pointer, preventing the intended drop.
Severity: MEDIUM — calendar drag-and-drop is broken for a specific layout, but the record date can be changed through other flows.
Root-cause hypothesis (medium confidence): packages/twenty-front/src/modules/object-record/record-calendar/month/components/RecordCalendarMonthBodyDay.tsx uses pointer-based detection for day cells, while sortable cards from record-calendar-card/components/RecordCalendarCardDraggableContainer.tsx can win collision resolution through their higher priority and default shape-intersection fallback.
Missing: The affected Twenty version or commit is not specified; the report otherwise includes a video and detailed reproduction conditions.

[sonarly]

🟡 Sonarly Analysis — Medium Severity

Collision priority selects overlapping calendar cards over the hovered day

Month-calendar drag-and-drop selects a populated day below the intended empty day when the dragged card overlaps existing cards. The card is then moved to the wrong column or cannot be dropped into the hovered column.

Root Cause

The month-calendar drop target is selected by dnd-kit's collision resolution before useRecordCalendarMonthDndKit computes the insertion index.

The calendar day registers a low-priority droppable:

useDroppable({
  id: dayKey,
  collisionPriority: DND_KIT_COLLISION_PRIORITY, // 1
  collisionDetector: pointerIntersection,
  type: RECORD_CALENDAR_CARD_DND_TYPE,
  accept: RECORD_CALENDAR_CARD_DND_TYPE,
});

Calendar cards use the shared sortable primitive, which registers every card with priority 3:

const SORTABLE_COLLISION_PRIORITY = 3;

useSortable({
  ...
  collisionPriority: SORTABLE_COLLISION_PRIORITY,
  ...
});

RecordCalendarCardDraggableContainer does not provide a card-specific collisionDetector, so cards use dnd-kit's default collision behavior. When the pointer is over the upper day but the translated dragged-card rectangle still overlaps cards in the populated day below, the populated card remains a collision candidate. Its priority of 3 beats the day droppable's priority of 1, so the lower card becomes event.operation.target.

The calendar hook then faithfully resolves the already-selected target. resolveDropFromPointer uses the target card's droppableId and index when the target is sortable; it does not re-evaluate the pointer against all day columns. Therefore the hook cannot correct a collision target chosen for the wrong day [ref:git-show-17ff17b] [ref:git-show-resolveDropFromPointer].

The triggering state is the specific month-grid geometry described by the issue: the intended day is directly above a populated day and the dragged card overlaps that lower day's cards. The dnd-kit calendar rewrite in b4aa3238895e5ad4d402d333a36b38164559e8ae replaced the previous @hello-pangea/dnd calendar implementation with useDroppable day containers and DragDropItemSortableCell cards, introducing the priority-based collision surface [ref:git-diff-b4aa323]. The later follow-up 17ff17bdec9b6abf826216c9dbe95f425ce76d59 changed the calendar resolver from the Y-specific helper to the generic resolver but did not change the card priority or add a card collision detector [ref:git-diff-17ff17b]. The issue was reported after those changes, but no deployment telemetry is available to prove which deployment exposed the behavior or whether it existed immediately after the original rewrite.

Blame commit: 3a8f086d by FelixMalfait — Converge drag and drop on shared dnd-kit primitives, remove @hello-pangea/dnd (#23211)

Suggested Fix

No files were changed. The exact fix should be applied after the dnd-kit calendar migration is present: allow the shared sortable primitive to accept an optional collision detector, pass pointerIntersection for calendar cards, and leave the calendar day droppable at its lower priority. This makes the hovered day win when the translated card rectangle overlaps cards in another day while preserving card-level insertion when the pointer is actually over a card.

---

Analyzed by Sonarly · View full analysis