FEATURE: Add inspector default group

[mhsdesign]

Neos part: neos/neos-development-collection#4068

Resolves: neos/neos-development-collection#4060

What I did
Use the same code like for the default tabs, but also check if an editor is set as always properties will be shown which dont have an editor configured

How I did it

How to verify it

[mficzel]

Could confirm that this works with properties that have an explicit editor configuration.
However properties that get the inspector configuration from the DefaultPropertyEditorPostprocessor are not affected.

Not yet sure what would be right but somehow think this should show up in the inspector:

  properties:
    text:
      type: string
      ui:
        label: A text field

This may be a naive assumption and could lead to all inline fields showing up in the inspector aswell which would be clearly wrong.

[mhsdesign]

Huh that’s interesting (thx for testing this so well :D)

I indeed implemented the check for the editor field, as otherwise all fields are shown in the inspector.

i don’t know yet how this correlates to the php nodeType processor (as it is in php and should have been already applied so the editor key should be set nevertheless but I might be wrong or haven’t looked in the right place )

[Sebobo]

I don't think fields without any kind of editor or inspector properties should show up. At least not with this initial change.
I know quite a bunch of nodetypes which have some properties from imported data and with labels to explain a bit better what they are for. But they should not be visible to editors.

[mhsdesign]

Yes youre right. @mficzel and me just discussed this in the weekly and we agreed to close this one as there is no good way in knowing whether the property is intendet to be shown or not.

So until we found better criteria ill close this okay? (The neos part, that we even have a default group, which can be used out of the box will stay - so its at least half of a win ^^)

[mhsdesign]

I just talked to @Sebobo about this and he is still a fan of this idea and mentioned: one can still use the option hidden: true instead of assigning no group to the property.

What do you think @mficzel ?

so we would need to write instead of:

_path:
    type: string
_name:
    type: string

this to hide the properties explicitly:

_path:
    type: string
    ui:
      inspector:
        hidden: true
_name:
    type: string
    ui:
      inspector:
        hidden: true

we could even try to provide a migration for this, or projects would see popping up previously hidden properties ...

[markusguenther]

Rebased the PR to 8.4 :)

[mficzel]

Using explicit hidden:true instead of non existing groups sounds like the right way to me.

Will need some documentation an I would consider this breaky and prefer a major release for that

[mficzel]

Fine by testing and discussing. Cannot say much about ts

[Sebobo]

There are integrators who use a non-existent group to hide stuff, I think even with a condition.

So the question would be: Should we have a third state: Match, Null, Non-existent group and hide that one still?