Recently I found out that our
Neos.Neos:ContentCollection only disallows Documents but allows everything else, even if the NodeType does not inherit from
This has never been a big issue in Neos as the UI prohibits other types from being used.
But when working with the CR (headless Neos f.e.) or when analysing the raw nodetype data, the constraint is different and one gets the option to add whatever they want to Content Collections.
So in https://github.com/neos/neos-development-collection/commit/b48660b28c1de596e74d4a95b8547d743b5199f1 in introduced a change in Neos 5.2 to define the correct constraint and disallow everything except Content.
But even though I had some tests to verify the behaviour, this broke the
Constraint best practices we taught the community because suddenly everything of type Content was allowed, even if they had
'*': false in their constraints. So to prevent everyone from adapting their existing project I reverted the change in https://github.com/neos/neos-development-collection/pull/2978.
I still want to fix this possibly with 6.0. But this is not so easy, because when disallowing
Neos.Neos:Content and allowing something like
My.Site:Constraint.MyCollection the inheritance distance of a Content element which implements both types is the same. And our algorithm in https://github.com/neos/neos-development-collection/blob/master/Neos.ContentRepository/Classes/Domain/Model/NodeType.php#L651 says: “If allow and disallow have the same distance, disallow wins.”.
Therefore it’s not easily possible to use constraints without a hack (like creating another abstract Content type).
This is an example of a structure that would not allow adding child nodes anymore when my initial bugfix is applied and with the current algorithm.
Meetup.Example:Content.Schedule: superTypes: Neos.Neos:Content: true Neos.Neos:ContentCollection: true constraints: nodeTypes: Neos.Neos:Content: false Meetup.Example:Constraint.Schedule: true Meetup.Example:Content.Schedule.Day: superTypes: Neos.Neos:Content: true Neos.Neos:ContentCollection: true Meetup.Example:Constraint.Schedule: true constraints: nodeTypes: Neos.Neos:Content: false Meetup.Example:Constraint.Schedule.Day: true Meetup.Example:Content.Schedule.Item: superTypes: Neos.Neos:Content: true Meetup.Example:Constraint.Schedule.Day: true Meetup.Example:Constraint.Schedule: abstract: true Meetup.Example:Constraint.Schedule.Day: abstract: true
What we need to think about:
How do we treat the case when allow and disallow have the same weight?
In the past the current behaviour was fine, as we mostly used blacklisting for NodeTypes.
But now that we have indirect whitelisting via the Constraints, this approach creates a problem.