Fixed
- Several Curator pickers bound to the same
MorphManyrelationship no longer clobber or duplicate each other's rows.
A form with more than one picker on a single relationship — featured, thumb, gallery, told apart by typeValue() — gained a row on every save, and the pickers displayed images belonging to their siblings.
The MorphMany save path reads and writes its rows in five places. Three of them disagreed about which rows belong to the picker doing the work:
- The update was not scoped by the type column, so saving the
featuredpicker rewrote thetypeof every row sharing thatmedia_id— including thethumbrow. The orphaned picker then found nothing of its own and created a replacement. One extra row per save, forever. Introduced in v5.0.6 by the sort-order fix: before that the update matched nothing at all, which was the sort-order bug itself. - Loading only applied the type filter when the type value was truthy, so a picker with no
typeValue()loaded every row on the relationship — including rows owned by typed siblings — and then wrote them back as untyped copies of itself. Present since v5.0.0. - The insert dropped falsy type values, so
->typeValue('0')— a backed enum whose first case is zero, for instance — stored a row that no later lookup could match, and every save appended another duplicate. Present since v5.0.0.
All five now scope identically. A null type value matches on type IS NULL, which is what the existing lookup and delete already relied on.
Reported in #734, fixed in #735 (thanks @appdezign) and #736. Four regression tests cover it.
Filament 4 users are covered — 5.x serves both majors.