Restrict Remove and Edit Settings for Fixed Part Definitions

[deanmarcussen]

Following on from suggestion on #4125 as something that could be done independantly of that.

If we create a Part Definition in a Migration which has fields, or via a recipe, and we define those fields on a Class, it would be great if we could restrict a couple of actions in the Admin

• Can or cannot, Delete the field from the Admin
• Can or cannot, edit the settings for the field

For me, when I've defined a Part Definition through a migration with Fields, it's often because I've written code that relies on those fields, (or the settings for the fields). So to be certain that the code won't break, removing access from the Admin is useful.

I'm suggesting that we can still change those definitions by using AlterPartDefintion in the migration, just not the UI.

Proposing two extra Part Definition Properties

• CanRemove, or IsRemovable
• CanConfigure or IsConfigurable

cc @johnrom

[johnrom]

I like the added properties, and I would lean towards the Is* versions. However, I wonder if this will be too limiting. Imagine I have a code-first content type, but I want to be able to add something to it. That new added part or field should be editable, and all the fields could be rearranged visually. So I wonder if IsRemovable for example would apply on the Field / Part level in relation to a content type (FieldMetaData and PartMetaData)?