I'm experimenting with the Editior Model Notifications and trying to hide a specific property from a specific element in a particular block list property without affecting everywhere else the element is used. Goal: Swap availability of a treenode selector depending on the area of the page the author is adding it to. For example: the main property is a treenode selector that has no restriction on item type selectable, but then property2 is a treenode with a more limited selection. Only 1 is available at any given time depending on the blocklist property the element is sitting in. The closest I've gotten is hiding the property's value... But can't seem to get at hiding the property itself. I've probably been staring at it too long, lol Snippet:

var rootProperty = notification.Content.Variants.FirstOrDefault()?
    .Tabs.SelectMany(f => f.Properties ?? [])
    .FirstOrDefault(f => f.Alias.InvariantEquals("region"));

if (rootProperty?.Value is not BlockValue blockList) { return; }

foreach (var block in blockList.ContentData.Where(block => block.ContentTypeKey == Constants.RCGuid))
{
    // using block.PropertyValues seems to affect nothing
    // this removes the selected value of the property...
    block.RawPropertyValues.Remove("reuseContent2");

}

If you use Block Grid you can have 2 element types and only allow them in each area. I know it's not block list but it's a solution to your requirements.

Yeh I was trying to avoid having different elements doing nearly exactly the same thing. I can hide element options in a BlockList using the handler (or just use separate lists), so Block Grid doesn't offer anything new there. It's lookin' like this just isn't possible. Which is fine. Can go the duplicate types route, just some tiny clutter so no real downside ;D

So for what I call 'Features' (element types / blocks that do things) I compose them from properties anyway. So I often have Features that differ by a few properties simply by exluding them from the composition.

Compositions are great but not really usable in this case since it's more that I need different data type restrictions on the property. It's not a matter of selecting different feature options for a component. These are effectively exactly the same and only 1 should appear at a time depending on the root property of the blocklist. This is an element with 1 field that's for selecting a node in the tree. The only difference between the 2nd field I wanted to have swap in/out based on which root property the blocklist was in, was a different restriction on the type of nodes selectable. You can use the notification handler to add/remove the display of what elements are selectable in a block list depending on the root property the blocklist is in, so I was just curious if I could take it a step further and not have a completely different docType but just swap a single property on the same docType. The best a composition can do for me is allow me to setup the view for these mirrored-types with a single IModel.

> The best a composition can do for me is allow me to setup the view for these mirrored-types with a single IModel Basically yes - I thought that was quite efficient but I can see that's not exactly what you are trying to do

I’ve done something similar but it was around hiding properties from specific users but no reason it couldn’t be changed to suit your need, I’ll dig out the code when I am in the office tomorrow. One thing to note is that if you remove the property you then have to worry about the save event as if the property is missing the value of it will be updated to null/empty depending on its data type. So what I had to do was then reset the value to its current value in the save notification.

I saw some examples of those but they were all based on root properties. Trick here was trying to get at a property on a specific element through a blocklist on a specific root property. I could get so close as to hiding the value of it but couldn't find the magic property to remove the field itself. A good to know on the save! Though that wouldn't be a problem cause in this case the hidden one should never have a value

Just an fyi on the notifications like content sending they have been removed in v14 in favour of doing this in JS, depending on the future plan for the site you might be better in the long run avoiding this approach. On the other hand here is the two handlers I have for this https://github.com/Matthew-Wise/feature-flagging-umbraco/tree/main/src/Our.FeatureFlags/NotificationHandlers

Ah k, I saw the warning on the v14 documentation but didn't know they were just being completely scrapped. No point in learning them then xD Though taking a look through anyways out of curiousity... this again just seems to work only on the root property not target any nested one? Or something to work backwards which don't think is possible.