There is this event in V8->v13 called SendingAllowedChildrenNotification that allows you to use c# to hook into the building of the list of types of documents you can create under a node. I was about to suggest somebody used it in V13, as a way to stop multiple 'Site Setting' nodes from being created, but thought I'd check it was still there, and I couldn't see it in V14? is it no longer a thing?? https://github.com/umbraco/Umbraco-CMS/blob/v13/contrib/src/Umbraco.Core/Notifications/SendingAllowedChildrenNotification.cs

That seems to be gone indeed, along with other notifications https://github.com/umbraco/Umbraco-CMS/pull/15855

Is there information about how to do the equivlent in V14 lit/vite brave new world? Most of the sites I've worked on use SendingContentNotification to update model before it's sent to the editor for editing, to provide default values and fix routing issues... where have you moved my cheese too?

^ its also how feature flags works 😦

Good to know 🙂 We are using

SendingContentNotification

as well e.g. to hide tabs, groups, properties, set properties as

ReadOnly

for specific backoffice user groups, changing view/editor of existing properties when re-using model in an overlay etc. I wonder how the equivalent of this would work in v14 😁

I was a big fan of

SendingContentNotification

, I used it a lot. Currently, there isn't an equivalent in v14. I'm unsure whether it's on the roadmap (post-v14), so I think it'd be best to start a discussion on the GitHub repo to lobby support for this (or alternative solutions). The crux of it will be about finding a good balance between backoffice client & server.

I think ultimately most of these are going to need to become front end extension points. V14 has a much stricter separation of back end and front end concerns so when talking about tweaking visual elements displaying, I think these are going to need to controlled on the front end. Equally, observable stores are a big concept on the front end which can be thought of as a bit of a caching layer, but really these stores need to hold full models and so altering models on the server would only make sense if those changes were permanent for the current session. I think a solution will need to come between the front end store and repository layers to allow these stores to hold the full models but allow changes as it is requested for specific use cases, ie editing. Not a solution, but maybe gives a bit of insight why these have gone from the server side.

I've had a bit of a play with MVC Global ResultFilters... and experimented with the AllowedChildren Sending Notification that allows you to customise the DocTypes that can be created underneath a certain node depending on the current users's User Groups etc

Wonder if its possible with middleware using something like:

app.MapWhen(
                context => context.Request.Path.Value!.Contains("endpoint", StringComparison.OrdinalIgnoreCase),
                appBranch =>
                {
                    appBranch.UseMiddleware<MyMiddleware>();
                });

Honestly, I wouldn’t waste my time trying to do it from the server end. I’d be looking at what could be implemented client side.

Yes, but it's not possible on the client side yet?

Server should control the model imo it makes sense in a headless app, let the server dictate what a user can see. Especially when it's permissions droven

All business logic SHOULD be in SQL Stored Procedures, it's inevitable!

What to clarify my frustration here if JS is the way that's fine but my question is why remove them what's the advantage? Off to go make the GitHub discussion 🙂

Don't be frustrated! - I think it's fine, what I have above with global filters is fine for now... it works well... it is possible to manipulate the data coming form api's using C#, it's a good stepping stone - if you had to build a V14 site and needed to set a default value when a page is created for a property editor, 'you could' achieve that with a global mvc filter- therefore it's not deprecated, it doesn't need to be announced as a breaking change and obsoleted for a major version before it's removed - it might not be the 'right way' and as the new backoffice matures, then over time something like this might be introduced back in, if there is a need... or the use cases that people have for using these events might be analysed and priortised, and if it turns out that X% of Umbraco sites all use one of these notifications to do a specific task, eg set a default value, then the answer might not be to provide these events willy nilly, but instead, provide a way to set a default value etc todays date for a blog post etc - get things out of code and into configuration etc

I just stumbled on to this and added something to the discussion on github started by @Matt Wise https://github.com/umbraco/Umbraco-CMS/discussions/16329

I'm not happy about this 😦 I also replied in the discussion on github

I really hope someone from the front-end team will come with some samples how to do this in the new backoffice (since I agree with Matt this should be handled client side) . So much implementations use this technique...