Entity autocomplete widget does not pass along entity to AJAX request

rebased ... and passed ... so i think we're back to review

For 9. patches ... i think it will be backported after ...

Was previously tagged for an issue summary update, if that can be completed.

Did not review.

Updated the issue summary with the proposed solution, implemented by #80. So back to Need Review.

Clone of the MR to see if it passes 11.x

Passed 11.x (committer can remove credit as I didn't do anything but reupload)

Reviewing the MR and changes look good.

Issue summary up to date.

Think it's good for committer review.

Left a few comments on the MR.

I do like the general approach here with the extra query parameters with just the type and ID, it's pretty much the only option that works and won't cause your key value table to explode over time unlike some of the related and similar issues, so +1 to RTBC once those pretty minor things from my review are addressed.

I do want to point out that the chosen approach does have some limitations, it will not pass along a new entity and it will not be able to pass along field values that have been changed in the current edit form, not directly anyway. So you won't be able to write a selection handler that will filter values based on another field reliably, not unless you save first that is. But the introduction of general support for query parameters should kind of allow to make that work when you alter the form element and add extra query parameters and some ajax refresh magic. A bit hacky, as your plugin will then need to read those again, but it should work.

And last: We should add a change record that documents that new feature I think and maybe also one that mentions that this now works (or a combined one).

Add small commit for MR for the request from MR review.

Could we consider the threads there resolved?

Left some comments in the MR

We also need a change record per comments above.

And did we decide to switch to key value expirable instead?

some updates for MR threads done.

it would be nice if we could close (resolve) some of them ... so we could focus on what's left ...

So NR ... "temporary"

@vasike can you update the MR for 11.x or start a new one.

Also appears to be 1 unanswered thread in the current MR.

Hiding patches

For now, updated the current MR with some Kernel tests.
Let's review ... then, if all good, we could move to the current dev branch - 11.x

Threads appear to be resolved. And tests look good. But think it would be good to add a test-only patch, then the updated MR. Hopefully that order doesn't trigger the bot.

let's try a patch file for 11.x

Since the MR for 10x was reviewed and feedback addressed. Think that carries over to the 11.x version of the patch.

updating issue credits

Committed 91f59e7 and pushed to 11.x. Thanks!

There is a new API here in the sense of a new render array key, but I don't think there is risk of that breaking anything, and this solves a valid bug in terms of missing feature parity for selection plugins depending on widget, so backported this to 10.1.x

Nice work everyone for getting this over the line

Automatically closed - issue fixed for 2 weeks with no activity.

It seems like there's still a difference between widgets. When using the OptionsWidget, $this->configuration['entity'] contains the current revision being edited. When using the autocomplete widget it's the default revision (because we are loading it by entity id).

Created 🐛 Entity autocomplete widget sends default revision to entity selection handler Active for that.