Currently, when you have manually sorted records:
You can drag and drop them to reposition them:
This updates their position property. However, currently, the system doesn’t separately track an updated vs published state for the position, regardless of the record’s current state.
In this example, that one repositioning (dragging Alfa to the bottom) will cause 7 events to fire:
When you have webhooks enabled, they’ll look like this: (not necessarily in this order; they all get sent out around the same time):
- UPDATE Alfa
- PUBLISH Alfa
- UPDATE Bravo
- PUBLISH Bravo
- UPDATE Charlie
- PUBLISH Charlie (just to update its position, even though the rest of that record remains in UPDATED status)
- UPDATE Delta (without a publish, since it was never published and remains in DRAFT status)
That’s 7 webhooks for a single move in a relatively small collection of just 4 records. For bigger collections, a single reposition can cause a cascade of hundreds of webhooks to fire all at the same time, overwhelming the webhook receivers with a flood of events.
Can we make this less painful somehow?
This isn’t a trivial thing to solve… some considerations:
- If each record’s position needs to have both a non-published (draft/updated) and published state, then that means the UI will need to be able to show this too, such as a collection-view preview mode that can show you the unpublished positions.
- This still doesn’t necessarily fix the webhook issue, either, it just separates the two (updates vs publishes), but with large models, each could still cause a flood on its own.
- It is already possible to records’ positions as metadata inside another record (i.e., via a multi-link field that enumerates them and allows manual positioning within the field), but the UX/UI for that is poor and takes editors out of the collections view.