Thanks for the suggestion @pySilver! This isn't something that we'd want to "bake in" to MultipleChooserPanel, since we don't want it to be limited to plain many-to-many relations - it needs to cover cases such as a slideshow where each slide is an image plus caption, and choosing an image once should not prevent using it again (with another caption).

I suppose the neatest approach here would be for MultipleChooserPanel to recognise when the inline child model has a unique_together constraint over the ForeignKey field named in chooser_field_name and the ParentalKey pointing back to the page (or snippet), and preventing duplicate selections in that case. Even then, there would probably be a lot of work involved on the UI side to make the chooser popup a true reflection of the current selected state (e.g. showing the already-selected items and persisting them when filtering/paginating) rather than just a mechanism for selecting new ones.

Good point. State issues :) What about passing the selection state back to the modal every time it's requested and handle unique optional requirement there.

I am also facing this issue, and ask if there is some known way to pass in a QS of options into the MultipleChooserPanel so that the choices in the modal are limited with some logic, either by unique to what's already saved in the model, or some other logic.

It seems that currently the most sane solution would be to get the reffer header from the request, and use that to reverse the url, get the object which is being edited, and then filter the QS based on that. IT doesn't include the current form state, but works well when adding a extra item to a unique list, as it'll only show valid non-duplciate rows.

The referer header is not reliable - browsers often block it for privacy reasons. However, passing a list of currently-selected object IDs to the chooser is not really the hard part - the hard part is keeping track of the currently selected items while navigating through the chooser.

currently selected items

Meaning: the current state of the model Form?

or

The currently edited object ID, is hard to track when navigating?

Even having the currently edited object in the request, would be a massive improvement.