Aggregated entity fields cause SchemaIncompleteException

Good point with schema but it means we have no test coverage for this handler, IS also needs update

I've tested on D10 site and haven't reproduced issue neither. I think, that patch from comment #51 🐛 Aggregated entity fields cause SchemaIncompleteException Needs review is enough for sites, using D9, while issue itself may be closed.

Still needs tests and an issue summary.

If not an issue for 10 then that should be documented in the code and version of the ticket changed.

Attaching patch with tests, which are taken from #20 comment. I've also updated issue summary with 2 possible solutions.

The Needs Review Queue Bot → tested this issue.

While you are making the above changes, we recommend that you convert this patch to a merge request → . Merge requests are preferred over patches. Be sure to hide the old patch files as well. (Converting an issue to a merge request without other contributions to the issue will not receive credit.)

While checking failed tests for my patch, I've discovered following points:
1) My solution doesn't work for latest versions of Drupal, because it adds more mess into config schema definition and it affects views more heavy, than I've expected, so I've focused on another solution of that issue.
2) I've put a bit wrong description on `Steps to reproduce` section. If we create field and then enable aggregation, than issue is not reproduced. But if we create view, enable aggregation, add field and set its aggregation to COUNT, than issue can be reproduced with latest version of Drupal. So we first need to enable aggregation and only then add field and set aggregation for it.

I've fixed `Steps to reproduce` section and also removed my solution from `Proposed resolution` section. I'm adding new patch, which is rebase of the patch from 33 comment. I couldn't generate interdiff, but basically it's rebase for D11 with couple of fixes. I've also added hook_post_update. I haven't run all tests, but the ones, which were failing are now good, at least locally.

I've created MR with changes from latest patch for further developing.

Thank you 🙏 Is there a way to prevent reordering in yml files?

As I understand no, because currently different mappings in schema contain plugin_id in their own place. In this issue we remove plugin_id from all these mappings and add it to the `views_handler` type at the first place.

Basically we don't need to reorder it for existing views, but we need to update default views from core modules, because otherwise tests fail. It happens, because test compares default config with actual and fails, as they are not the same.

I've pushed phpcs fix into MR, not sure, that I need to update patch for it.

Appears to have test failures. Also believe we will need a simple test for the post_update hook.

rebased from latest 11.x

rebased again and fixed phpcs error

but we still have failed tests (btw unsure why do we have some changes in tests assertions in MR)

What is the purpose of 🌱 Make views consistent in code, schema, tests, and APIs Needs review