FEATURE: Mark inherited disabled nodes in document and content tree

[dlubitz]

Fixes #3896

This marks nodes, which are disabled by inheritence, because a ancestor node is disabled, with a dedicated icon.

[mhsdesign]

all this stuff is slightly getting more and more bloated ... i dont like that :D maybe we should do something similar to what we have done with other data: use bit masks ... this is especially useful to denote that there is likely of all the things only one state that we really want to highlight in the ui.

neos-ui/packages/neos-ui-redux-store/src/CR/Workspaces/index.ts

Lines 12 to 17 in 81d01be

	export enum TypeOfChange {
	NODE_HAS_BEEN_CREATED = 0b0001,
	NODE_HAS_BEEN_CHANGED = 0b0010,
	NODE_HAS_BEEN_MOVED = 0b0100,
	NODE_HAS_BEEN_DELETED = 0b1000
	}

aside from this the chnage looks good :D Code wise it looks fine and should work ... is there anything missing than to disucss if we like to keep introducing data bloat :D ?

[dlubitz]

I've rebased this on 9.2 so we can have it there as a feature.

[mhsdesign]

Hi, i see you have also created #4161 but this feature pr is not feature complete without would behave buggy - e.g not update? We cannot have one without the other ...

but speaking about the other ... the change introduces more complexity to our already hopeless tree.

I am restricting myself to adding more features to the tree - for example i wanted to show deleted nodes to allow their publication - and rather started to work on incorporating a new foundation for our tree which is fully server/php backed and should also be fast.

#3944

The problem is that it was not a super big priority so far. Our current tree is already not maintainable and fully undertested by E2E tests.

I think as developers we cannot add more and more things this broken tree but must refactor first and consider there the features we would like for a version 2 like showing and updating inherited nodes as well as showing deleted nodes as well as a possible way to paginate.

[mhsdesign]

An alternative we could consider is to still have this feature on our current tree implementation but add e2e tests for all scenarios and then later switch out the implementation ... but that still makes our current tree more complex which it can barely handle

[dlubitz]

I see your point, but stopping developing at all is also not an option for me. IF there were already hard progress on rewriting thing, ok. But nobody seems to work active on this.

This PR here works stand alone for the current node. BUT the child nodes are not updated immediatelly. Only a manual reload of the trees/full UI shows the hidden children. And yes, this was basically the idea of this change.