Add a way to automatically add a part to a content type

[MikeAlhayek]

Is your feature request related to a problem? Please describe.

If we look at the implementation of the Admin Dashboard, we'll notice that the user has to specify a DashboardWidget Sterotype in addition to attaching DashboardPart part. I think there should be a way to allow us to inject a driver automatically based on conditions (for example stereotype).

Describe the solution you'd like

I think we should add a way "maybe options" that would allow us to specify which part to attach and when. So we can say attach X part to Y content type everytime "no optional". User's can't remove it, but user can change it's position as needed. This will simplify the steps on user need to do for this kind of scenario.

Maybe we can add event handling to the content definition manager where we can auto inject a part directly when loading/updating a content type of X stereotype (or any other custom logic). The add a new option to the content part definition "IsRemovable" for the UI.

[Piedone]

Parts can be attached to content items (not types) on the fly based on arbitrary logic from handlers. Isn't that suitable?

[MikeAlhayek]

I understand that. One can use ContentHandler to inject a part automatically to content item. But, that would give the user no control on where to place the content part.

But, if we have a way to always add the part to the content definition, then the user can change the part position "drag/drop", then creating new content item will create a UI from the content definition "which includes" the forced part at the position that admin wants.

[Piedone]

There's also IContentDefinitionEventHandler that you can use to alter the content definition e.g. when you create it, so parts can be attached when creating a type with a given stereotype.

We could add an Removable config to ContentPartSettings indeed, as a pair to Attachable, to govern manual removal.

[MikeAlhayek]

Lol. I did not know we already have event handler for the content definition manager. I did a quick peek before opening the issue but did not see it.

We should be able to use that handler to achieve this. I'll give it a try when time permits

[sebastienros]

Other suggestion that was discussed, to have some new properties on the Type to make it behave like an "abstract" type, or base type only, this way it could appear in the Create Content Type UI as an option instead of a blank new one. The new type would copy the stereotype, parts, settings, ... and just have a new name. Then its parts/fields would not be removable (custom setting or property).

This way the editor behaves the same, there is no dynamically added part (that could conflict with when it is attached vs. when we need to use it).

If there is a new flag on the "abstract" content types, then this could also be displayed in the Content Type editor to create such new content types. And reuse recipes to create them too.

[github-actions]

We triaged this issue and set the milestone according to the priority we think is appropriate (see the docs on how we triage and prioritize issues).

This indicates when the core team may start working on it. However, if you'd like to contribute, we'd warmly welcome you to do that anytime. See our guide on contributions here.