I personally couldn't reproduce the issue when following the steps. It's working as expected for me.

The addition of allowedBlocks to the group block postdates this particular deprecation, so I wouldn't expect it to need to be added.

@sque89 You may need to narrow down the steps for reproduction. Are you using a clean install of WordPress/Gutenberg when testing or do you have other plugins installed?

@talldan thanks a lot for having a look and you are right, i missed a crucial precondition to this issue, sorry. I updated the steps to reproduce and added a screenshot of the relevant part in the code (it is the deprecated.js of the core/group block.

My custom blocks still use the layout inherit option which was apparently deprecated which is the reason why the latest deprecation is eligible for my group blocks.

If that is the case, in the current version, the attributes passed into this deprecation migration do not contain the allowedBlocks attribute, so it gets omitted completely.

Adding the attribute to this deprecation fixes the issue, but as said i am not sure if that is the right way to fix it, or if there is maybe a broader underlaying issue of attribute migration.

Any news on this one? It basically breaks my whole enforced layout of our custom blocks because people can start adding anything inside the group which is not desired.

@talldan would appreciate if you may could have a look at my answer to your comment. This one is a pretty big problem for us currently. Thanks!

The following accounts have interacted with this PR and/or linked issues. I will continue to update these lists as activity occurs. You can also manually ask me to refresh this list by adding the props-bot label.

Unlinked Accounts

The following contributors have not linked their GitHub and WordPress.org accounts: @robins@animalequality.de.

Contributors, please read how to link your accounts to ensure your work is properly credited in WordPress releases.

If you're merging code through a pull request on GitHub, copy and paste the following into the bottom of the merge commit message.

Unlinked contributors: robins@animalequality.de.

Co-authored-by: talldan <talldanwp@git.wordpress.org>
Co-authored-by: sque89 <sque@git.wordpress.org>
Co-authored-by: tellthemachines <isabel_brison@git.wordpress.org>

To understand the WordPress project's expectations around crediting contributors, please review the Contributor Attribution page in the Core Handbook.

@sque89 Sorry for the delay responding, it's been a busy time.

It would definitely be great to get this issue fixed, though I'm unsure what the right way to fix it is.

My understanding is a deprecation should represent a version of a block almost as a snapshot in time, so if the block didn't have allowedBlocks when the deprecation was created, it shouldn't need it.

I guess what's happening here is that the isElligible method is still causing the deprecation to run even on newer versions of the block 🤔

Deprecations are a generally tricky area—I'll ask for some other input to see if we can help this one across the line.

Hello there @sque89,

"layout":{"inherit":true} was deprecated while layout was still an experimental feature, so there's no back compat requirement for it. Even so, back compat has been maintained for it to avoid breakage of existing websites, and that's why it still works for your custom blocks.

The stable equivalent layout is layout: { type: 'constrained' }. If you update your custom blocks to use that format instead of "layout":{"inherit":true}, everything should work as expected.

@talldan thanks for getting back on this. But i need to admit that i never looked at it the way @tellthemachines described it. If the feature never left the experimental state and was deprecated in that state, of course this needs to be considered as bad luck. That is exactly the risk when using experimental features.

So after considering that it would be fine for me to ignore this and i will handle the issue myself on our side by updating the blocks.

Thanks to you too for your time, i will close this PR.

Thanks @sque89, glad a solution was found for you.