Disable to remove Code defined Part or PartField

[hyzx86]

Currently we have many ContentTypes or Parts defined in Feature.

Just like Menu ,List,Taxonomy , etc.

If remove some ContentTypes or Parts through the admin dashboard, it may cause problems with the functionality that depends on these definitions, and there seems to be no way to distinguish between them at the moment

Is there any way to check if the ContentTypes , Parts or PartField is already defined in the code? To hide the delete button

[hishamco]

May be we need to disable delete button in case that the content type or part has been used, @MikeAlhayek remind me if you implement this in OC before?

[MikeAlhayek]

@hishamco there was ones a PR (#11737) that we ended up closing that would allow the use to disable listing that content item in the UI. However, it was decided that we did not want to take it.

The problem is that content definition can be altered in many way like migration, recipe, UI and probably API too or even workflow.

@hyzx86 if you create a controller that require a content type to work, you can check the definition manager to see if that content type exists before you continue. If you have a part that is critical to a type, you may want to make that part a C# type not based on fields. Then, you can weld that part the content item using a handler. This will ensure that your type always has it and the user is unable to remove it or manage it via the UI.

[hishamco]

Thanks that my memory is not volatile :) I remembered there's a PR related to you

The problem is that content definition can be altered in many way like migration, recipe, UI and probably API too or even workflow.

If the content definition is altered I presume it should affect the UI, right?

[MikeAlhayek]

yes the UI render based on the content definitions. but if he creates a C# part, then it won't be part of the definition and it won't show up on the UI. And since he would be using handler to attach the part, the user has no way to altering the behavior.

[hishamco]

it won't show up on the UI.

I didn't try it but I presume it should reflect while it affect the same content definition

[hyzx86]

I had an idea, like when we register a type in the code, we also register the name of the type with the scope, if this feature is enabled, then this Part will not be able to be removed

services.AddContentPart<DIndexPart>();

If this feature is turned off, we can remove the type
But we may have to perform the migration again when re-enable the module

that only solves part of the problem

[MikeAlhayek]

If you follow my last approach, you'll have a solution that works. You register your custom part, driver and a handler in the feature you want to use. When that feature is enabled, that part is auto weld to the content type you set in the handler. If we disable that part, everything goes away.