Removal of SendingXNotifications in v14

[Matthew-Wise]

I think these notifications have been undervalued and shouldn't be removed in v14. They are quick to make little tweaks to what the back office allows a user to do. In particular SendingContentNotification.

I get the want for Front end/ Back end separation, manipulation the data sent to the front end is really useful. This might be a case of where's my cheese, but would like to at least know why.

discord link - https://discord.com/channels/869656431308189746/1238039395748020275 (will post this link here ofc)

[dawoe]

I just stumbled on this because I am preparing for a upgrade to V14. This will prevent us to do a upgrade.
We use a lot of these notifications in our current V13 project.

Also I think it's very strange this get's removed without any heads up. This is in conflict with Umbraco's own deprication policy :

When we need to remove something from i.e. the public API, we will release a minor version with the deprecation in it, and keep it around for the next major as well (so announced deprecation in 10.2.0 means it will no longer be available in 12.0.0).

See : https://umbraco.com/products/knowledge-center/versioning-and-release-cadence/

Some of the use cases of these events can be found in the code examples of my DF22 talk : https://github.com/dawoe/df22-journey-into-the-unknown/tree/main
But there are more : disabling preview, removing links, setting default property values, making properties readonly.

But what makes it even worse a lot the things removed in this PR (#15855) are still documented.
https://docs.umbraco.com/umbraco-cms/reference/notifications/editormodel-notifications
https://docs.umbraco.com/umbraco-cms/customizing/section-trees/searchable-trees
https://docs.umbraco.com/umbraco-cms/reference/content-delivery-api/additional-preview-environments-support#configuring-custom-preview-urls

And as it seems there is no alternative.

[nielslyngsoe]

Thanks for chipping in @bjarnef, I would like to know more about hiding some or specific properties, what would these conditions be? And are we talking a combination of multiple? It would be lovely if you could explain the different cases/personas to get an idea about the flexibility.

[bjarnef]

Often we would to hide specific properties, tabs, groups or content apps for editors, but no matter what it doesn't effect admin users.
E.g. we could store some keys, settings on nodes or blocks, which rarely change and content editors don't need to worry about (and we want to avoid they mess up with these and eventually break stuff).

But we also have a more complex use case for a Course node type, where some users shouldn't be able to edit properties depending on their user access.
In this case:

• User has access to one or more businesses node (branches) via start node ids.
• Each business has one or more secretariat related
• Each secretariat has one or more committee

Then one course node a FKB list (MNTP) and on commitee node selected FKBs. Depending on matching Guid and a match was found, all properties under a "Course data" tab was made readonly, the other tabs were hidden, and we also hidden some actions like update, publish, unpublish, rollback and delete.

So in short the user has access to manage some course nodes depending on which business/branch/category it belongs to.

[nielslyngsoe]

Thanks @bjarnef, Is this just for UI hiding?, or do you revert back data so it is not possible to hack if you where calling the end-points on your own?

[bjarnef]

@nielslyngsoe mainly for UI hiding - or that would be a great start, but in an ideal world there may be properties some users shouldn't be able to modify. In our use-case ideally the users shouldn't be able to modify some properties, but we could live with the properties not being rendered.

Perhaps consider:

• Hide properties for specific user groups (or all besides admin)
• Hide properties per content type (eventually multiple content types)
• Hide properties based on more specific logic, e.g. an content editor may have access for a property on Course A, but not on Course B.

[dawoe]

@nielslyngsoe @bjarnef

We also use it for making properties read only. We often have to import content into Umbraco from external systems. Data coming from external systems, should not be edited in Umbraco so we make those properties readonly.

[Luuk1983]

oof, this sucks! I'm preparing to update a number of our packages to Umbraco 15 and we have quite some logic to manipulates the menu's in Umbraco. I don't mind if this logic needs to go somewhere else, but it seems that there is currently no alternative...? I understand the need to rework the backoffice and I think it's a very good step towards the future, but tbh, as a company, it's a complete pain in the butt.

[Luuk1983]

@nielslyngsoe Ofcourse! We use these notifications to make sure the client doesn't not do things that could break the frontend.

We use the MenuRenderingNotification to remove the delete button on content that should not be removed. Think of the 404 page or the homepage. If the user is an administrator, we don't remove the delete button but modify it with a different icon to make sure the administrator understands that he or she needs to be really sure before deleting that node. Yes I know that you could achieve this with user rights, but to be honest, the rights and roles system in Umbraco is so incredibly unflexible, so this works way better.

Next to that we use the SendingAllowedChildrenNotification to also enforce content rules. For instance, we allow only one 404-page content type to be present on the site, so when a 404-page is already present, we remove the option to insert it from the allowed children. Or sometimes we want a editor only to be ablee to add a maximum number of children of a certain type and we also enforce that using these rules.

So in short, it's to define business rules when it comes to content. If you need more in-depth information or code examples, let me know!

[nielslyngsoe]

@Luuk1983 thanks!

I hear that the permission system is complex. And I think it might always be, so some code/API approach to append/manipulate permissions might be the way to go? As somethings are just simpler to handle in code. What do you think about that idea?

[Luuk1983]

@Luuk1983 thanks!

I hear that the permission system is complex. And I think it might always be, so some code/API approach to append/manipulate permissions might be the way to go? As somethings are just simpler to handle in code. What do you think about that idea?

My issue with the Umbraco permission system is that it's extremely limited and imho one of THE major weaknes of Umbraco when it comes to larger sites with multiple editors. In Sitecore (barf), I would simply deny the deletion of the homepage node for all users independent of the rest of the roles. But Umbraco does not really support having complex access rules like deny access that can take precedence over allow rules. If you add multiple roles to a user, you can only give a user MORE access, never less. If the permission system were more flexible, I would definitely use that for the removal of the delete button. But since it isn't more flexible, something in code would be nice.

But for the handling of 'allowed children notification', something in code or an API would be the way to go for me. This is just enforcing business rules based on some criteria. In Umbraco 13 I'm using the appSettings for configuring the business rules, so for me it would be very nice to have access to the settings as defined in appSettings.

[AndyButland]

With regard to the "allowed children notification" the plan we have for this is in this PR.

We also have a PR pending for the documentation that will replace the out of date information we currently show with details of the method supported in Umbraco 15. This is planned as part of the 15.2 release.

[Luuk1983]

@AndyButland, looks good!

[lumimario]

I came across this problem while creating a new package for Umbraco. I can't move forward if there's no alternative for this. And I know many other packages that use these notifications to make changes to the backoffice.

We're already in v15 and it's definitely not ready for production unless you just want a simple site.

[nielslyngsoe]

Hi @lumimario I would like to know about your use case. Because the Sending Notifications can be used for many different things. I would like to ask if you could you let me in on your needs for this? Especially what is it you like to achieve. Thanks

[lumimario]

Hi @nielslyngsoe , at the moment I was going to use SendingContentNotification to set default values in some properties on the page. Also I wanted to hide the Links box in some doctypes that I want to use as 'data' nodes, not real pages.

[nielslyngsoe]

Thanks @lumimario, I can already say that we are looking into resolving these two cases from a client code perspective — not because we do not want to handle this from C# but because that is a more appropriate place for this to be handled.

The boxes on the info pages, will become individual extension, enabling you to exclude, setup conditions for it or even overwrite with your own. (will happen soon)
— In this way the data is not going away, potentially breaking features, so much more safe just to manipulate the UI.

Regarding default values, which for clarity I will name 'Preset Values'. We are aiming for this to be solved via client extensions, its still just on a conceptual level. Doing this will open up for contextual logic, enabling to use the Context API to resolve the value you like pre-set. — Giving you freedom to connect with what you like to get the value you like. :-)

[lrirlu]

While I haven’t used SendingContentNotification directly, I had been exploring its use for a now seemingly unsupported scenario. After all the v15 documentation still references editor model notifications, which adds to the confusion.

Here’s the use case I was working on:
I have a document type with properties that define its "state," specifically:

• startDate
• endDate
• publish-status

The content is "Active" if published and the current time is between startDate and endDate; otherwise, it’s "Inactive."

My goal was to compute this state as a readonly property in order to:

• Clarify content status for editors: Reduce confusion and save overhead by showing a transparent, calculated "Active/Inactive" state during editing.
• Enable sorting by state in list views: Especially when parent content has list-view enabled, sorting children by computed state would add significant value.
  Previously, I was exploring SendingContentNotification as a hook to dynamically calculate and populate this information. However, with its deprecation, I’m uncertain about the best approach moving forward.

Are there alternative patterns, workflows, or extension points in v15 that would support this type of dynamic computation and communication to editors? Any guidance or clarification would be much appreciated.

I’m still relatively new to Umbraco, so I may have overlooked an obvious approach.

[nielslyngsoe]

Hi @lrirlu

It sounds like you are trying to make your own version of the Scheduled Publishing feature?

These three properties are already available in the Document model, and can thereby be utilized by the UI if you like it to be presented even more explicit. — But if you have some time I can share that we will be improving the clarification(Visibility in the UI) of this state in near future.

And the Collection View(List View in v.13) already supports sorting by the Publishing State.

But I hear that you would have used this feature to append extra fields, I'm not sure that would have even worked well for the Collection View as the sorting is happening on the server and the Sending Notifications is a manipulation happening between Server and Client.

If you feel like clarifying or explaining other needs then I would love to hear them, thanks

[marcemarc]

I've had a scoot through a few of the repositories for existing sites, (which will one day need to be migrated) where these kinds of techniques have been utilised, with an attempt to uncover common use cases. My intention was to do a talk called 'Who grated my cheese?' - showing how those quick and easy c# enhancements and workarounds that implementers have relied on for years, could be reimagined in belissima, but also understanding the use cases might lead to better solutions to the problems than the c# events provided.

Ref	Event	Use Case Ramblings	Thoughts
1	EditorSendingContentNotification	In multi-territory site (different cultures) eg not using variants - there is a bug where you get 'Urls' generated in the Links section for every language/culture created in the languages section of Umbraco, when there should only be a Url for the Culture and Hostname of the current site tree... You could remove the out of the box DefaultUrlProvider and write your own, but then you are maintaining something bespoke, whereas using the EditorSendingContentNotification, to workaround, by getting the ParentId of the current node and using GetCultureFromDomains() and then filtering the notification.Content.Urls property accordingly, so editors only see relevant urls to the content available in their tree (sometimes editors don't have permissions to the content in other branches, but still see the Urls in the pages they are editing!)	Better to fix DefaultUrlProvider for multi-tree, multi-lingual setups.
2	EditorSendingContentNotification	With custom UrlProviders you are meant to be able to add your own UrlProvider to the stack, and in the past (v7) this enabled you to set a custom message that explains to the editors more clearly for each different type (eg 'Published: This is a settings component or folder and has no direct Url' or 'Redirects to first news article' instead of the less friendly 'This document is published but..') - but because of this bug: #15343 you can no longer do that! but the workaround is to use the EditorSendingContentNotification to set that friendly Url status message	Better to have ability to customize the message per DocumentType when it cannot be routed, this feels less the responsibility of the UrlProvider if it is 'backoffice only'?
3	EditorSendingContentNotification	used to migrate one property type to another property type, one at a time - for a large site if you are switching the way that content is managed for a particular part of the site, either by switching an editor type to another editor type, or by adding a new editor type alongside - then since the published cache is not immediately updated - we often use the EditorSendingContentNotification to perform the migration of the data on that single item, whenever it is next edited or as part of a planned manual migration - this gives the editor chance to review (perhaps we can only migrate the text, and they need to pick things again) and approve the migration change and publish. It's basically a really nice workflow.	this is one of those scenarios where the adhoc flexibility allows you to do some really nice things for editors in the context of a situation - but maybe it should not be that flexible!
4A	EditorSendingContentNotification	in a multi-site situation, eg the company has microsites on different parts of the business, or even different coloured themes for different sections - then you might have theme or colour options that are specific to the tree of the site you are editing on, or they might have the same options but different defaults - the SendingContentNotification is then used to find which branch of the site is being edited and either limit the options available for theming the site, or set a different default theme/colour	so we are describing some kind of 'tree context aware' ability to refine the properties and settings available to an editor on a particular document type and to set different default values
4B	EditorSendingContentNotification	in a multi site situation, where you might want to have a common set of blocks, or have a custom property editor within a block, and you want to change the colour theming options based on which tree you are in, then inside that editor you can't easily get access to the ParentId that the page is being created on, and therefore can't get the context of the site being edited, here, you use the EditorSendingContentNotification to put the ParentId into a Session object scoped to the current editor, and then when they are inside the block editor, the custom property editor within that block can access the session to work out which site is being edited and respond accordingly.	(I think latest Contentment in v13 has a workaround for this, but I think it's more about flagging the use cases, so new ways can be found, so there is nothing you really need these c# events for) - So a sort of unified way for a block editor to get the context of the page/tree it is being created on, and the ability to refine it's properties and settings based on this context and set different default values.
5	EditorSendingContentNotification	Hide preview button when there is nothing to preview (eg no template)	This is probably more part of a conversation around having 'Published Elements' in the tree, that are non routable, it's always been possible, and Umbraco has always generated a link that 404s if it's clicked - for me, the preview/save button shouldn't appear for a node without a template, only save - breaking change! but it should be possible to wire up the save and preview to a custom url, if you are doing a niche thing of headless or handling the template rendering outside of Umbraco. or could it be a document type setting?
6	EditorSendingContentNotification	setting custom PublishedDate for a new Blog or News Article to be todays date, and similar setting helpful defaults - you could set these with the content service saving event, and have editors learn they need to leave the date blank if they want the default value to be applied, or assumed at runtime, but it's just a nicer editorial experience if the editor is presented with the default values but has chance to override them before publishing.	This is a helpful contextual default value rather than a fallback value and one of the commonest use cases, but from conversations at UK fest, it might be one of those things that HQ feel should not be possible, the suggestion was to always handle this at the point of rendering, but it's hard to accept as we love to feel that we are improving UX and editorial experience in the backoffice for our editors, even if we are wrong :-P
7	EditorSendingContentNotification	to make some properties readonly for some users, if they are not allowed to change a particular setting, but special people are allowed, this is useful in variant/nonvariant scenarios where you want the default language editor to set the image, but only allow the foreign language editor to update the text around the image	maybe handled in future by complex granular property level permissions model and property editor status, but how that is then handled with custom property editors is also a puzzle.
8	EditorSendingContentNotification	to hide legacy property editors or tabs - often with a site upgraded since V4... all the way!! - it has nested Document Type structures, with common properties set at the base level, you might as you create new Document types to take advantage of new editing paradigms, be forced into using that inheritance chain, but only be migrating sections bit by bit, Document Type by Document Type - currently we can hide the inherited legacy property editors from the UI for some Document Types, or do so when data has been provided for the new field - and quickly enhance the experience for the editors with the new Document Types during the migration and benefit the business by delaying the need for expensive restructuring of document types and migration of content to a more convenient future date for the business.	Working with Umbraco sites, isn't always about 'just' building from scratch, this notification is often utilised when affecting transition, but should that be a consideration for HQ?
9	EditorSendingContentNotification	Implementing a front end 'lockdown' experience, it's not always possible to lock editing and development environments by IP Address - even for some extremely large corporations! - lots of agencies have developed a lockdown mechanism that involves generating a user token hash, that when presented on the querystring will allow access to the front end of the preview environments for a short period of time, the EditorSendingContentNotification is used to append this querystring value to the Urls in the backoffice, so the editor doesn't have to think when they click to see the development environment front end, they just get temporary access.	Maybe this functionality is better achieved via being able to adapt the output of the UrlProviders, once they have all run, then you could detect whether it's a backoffice request, and add tokens to existing Urls or remove them, and then this is nothing to do with the EditorSendingContentNotification model. Currently it's not possible ONLY with custom UrlProviders.
10	EditorSendingContentNotification	In a load balanced configuration, there is an instance for the Umbraco Backoffice for editors to use and a scalable front end instance for the site to be published to the outside world on - these two environments share a database but have different domains, however in the backoffice when the editor looks at the list of Urls they end up with two Urls, one 'relative' url for the backoffice and one for the published domain, this often leads to editors clicking the 'top one' and sharing the backoffice domain to the outside world, therefore we use the EditorSendingContentNotification to always remove the relative Url from the list of notification.Content.Urls so this doesn't accidentally happen.	again it's a way to customize the output of the UrlProviders, once they have run for the backoffice Links.
11	EditorSendingMediaNotification	The link and url shown for a media item, hides the full path, in the links box you only see the filename, the SendingMediaNotification can be used to display the full path to the editor, and in the case of load balanced environments, prepend the domain of the front end of the site, so that when the editor shares the Url to the file to the outside world they don't accidentally share the backoffice Url.	I don't have a load balanced V15 to check... but it does show the full path rather than just the filename to the editor, also I can't truly remember why this wasn't achievable via a custom IMediaUrlProvider.
12	ServerVariablesParsingNotification	when the front end of the site and a custom backoffice property editor share the same configuration, eg google api key, then it's handy to be able to specify and manage this secret key in appsettings, to take advantage of local visual studio secrets and keyvault configuration methodology, to manage the setting in one place. The ServerVariablesPassingNotification gives a method for reading the value in c# and adding it to ServerVariables that can be accessed from the custom property editor.	A way for custom property editors to access appsetting values, presumably doable via an API call?
13	TreeNodeRenderingNotification	Changing the colour of an icon based on the value of a property in the Media Item or Content Item, to indicate status to editors without having to open up the node to check - for example to indicate that a Media Item is missing a value for its AltText property or to show the Media Item isn't being used on the site - or to show that the Content item in the tree has been redirected (redirectUrl property filled in) or that the content item is a 'placeholder' node and hasn't had its content migrated yet, (in a strangler fig scenario) but, exists in the tree to provide structure.	It's hard to envisage how this would be normalized as a feature, but it is another super common enhancement - blame Paul Seal! :-P - solves the editorial painpont: "!don't make me drill down to find something out" - maybe the new tree collections are able to do this? - not sure how these rules would be defined outside of code, at a component level vs doctype level?
14	MenuRenderingNotification	Hijacking a menu item to change its implementation to a different path, to improve backoffice dialogs. Eg to apply granular access to entries of Umbraco Forms, making clicking on the form to edit it, just go to 'entries' path for some users, or in a Authoring / Production split environment, where Production is completely locked down for editors - have the form entries loaded from the production database.	Maybe a feature of Umbraco Forms to enable it to store and display entries from a custom database table.
15	RootNodeRenderingNotification	Remove certain Trees from sections based on user context, for some editors we need to give access to the 'Content Templates' (blueprints) in Settings or the Log Viewer, but not see or edit other trees in that section - Permissions are section baserd but RootNodeRendering allows you to customize what is available for specific users	Maybe this reveals a possible need for a different section by default for things like 'Content Templates' and maintenance tasks such as viewing logs, that is different to editing Document Types etc? or maybe permissions are applicable at the Tree level?
16	RootNodeRenderingNotification	Remove certain Trees from sections based on environment - for some sites, we have complete lockdown of being able to change things in Production, and so we remove trees from settings section when they should not be used in production, there is the existing ProductionMode which makes things readonly, but it doesn't go far enough, we leave only the Log Viewer, Content Templates, uSync, God Mode visible	again maybe this indicates a need for a different default section? a 'Maintenance' section rather than 'settings' then there is less need for tree level granularity?
17	ISearchableTree	Adding custom search logic to the backoffice search, for example searching by Dictionary Key and Dictionary Value - the editor only sees the text on the front end and doesn't know what the key name is that the crazy developer has created, but by searching by the text they see rendered on the page they can reverse find the dictionary key.	maybe this is part of the backoffice search RFC discussions, but it was useful to be able to extend the scope of what was being searched and how.
18	UmbracoTreeSearcherFields	this was a quick way to add which fields would be searchable in the backoffice, so on a site that stored products as nodes, being able to search for matches in the ProductSKU field in the backoffice search, was super useful for the task of finding and editing products	I'm not actually sure if this still exists in V15?
19	MemberListViewSearch	this isn't a c# event but a rogue hacking of the angularJS, but the use case is that sites that use Members, sometimes use the Umbraco Members section as the basis of their Membership platform, this almost always meant they want to be able to 'search' the ListView (not the backoffice search) by custom properties, beyond the name of the Member, so we tend to hijack the angularJS as per Soren's article - https://dev.to/skttl/how-to-customize-searching-in-umbraco-list-views-1knk soren to achieve this. Also in the above products example we also made the products listview search, search for the SKU to with this angularJS hijacking	maybe this is part of the backoffice search RFC?
20	ContentNodeInfoDirective	this isn't a c# event, but when we configure a production environment that needs to be locked down for people tinkering with DocTypes etc, and we use the RootNodeRendering notification to remove them, in the content item info panel, there remains handy 'Open Template' and 'Open Document Type' links - but these now error, so to remove these, we hijack the umbContentNodeInfoDirective, read a value we've added to Sys.ServerVariables to determine if we are locked down and if we are we replace in the directive.template 'allowChangeDocumentType' and 'allowChangeTemplate' to be 'false' to hide the buttons	Maybe there is a new feature to ProductionMode that will take care of removing trees and these options, but again highlights a split between 'maintenance' and 'settings', where to maintain a site you need 'maintenance' things, but in a locked down environment, you don't need access to 'settings'

Anyway hope this gives some insights into how these kind of things were used, and hopefully you can see by listing the use cases, and thinking about them, very rarely is the conclusion, we just need those c# events back!! They were largely introduced to 'bat off' niche requests of Umbraco core functionality, but now can see the dialogue is shirting around to t lets make Umbraco be able to do more of these things without custom ad-hoc workarounds, you can see even, by using these events we are hiding the existence of bugs!

After years of using them, these c# events are firmly embedded in the toolbelt of quick and easy Umbraco solutions, to move forwards we just need to grasp how to achieve the same but differently in the future, upgraded V13 sites are still probably the biggest target audience for new Umbraco 15+ sites, the sooner we can remove the barriers to migration the sooner we can have the new cheese...

First slide:

[bjarnef]

A comment about EditorSendingContentNotification and "Hide preview button when there is nothing to preview (eg no template)":

for me, the preview/save button shouldn't appear for a node without a template, only save

We should be careful about just hiding preview button if no template has been assigned, because for a long time it as been possible to handle this in render controller returning the view even though no template has been created (in database) and assigned to node (template id reference) in backoffice and only psychical template on disk exists. In that case preview would still make sense and work OOTB.

[marcemarc]

We should be careful about just hiding preview button if no template has been assigned, because for a long time it as been possible to handle this in render controller returning the view even though no template has been created (in database) and assigned to node (template id reference) in backoffice and only psychical template on disk exists. In that case preview would still make sense and work OOTB.

don't worry bjarnef, I do follow that statement with a caveat:

• breaking change! but it should be possible to wire up the save and preview to a custom url, if you are doing a niche thing of headless or handling the template rendering outside of Umbraco. or could it be a document type setting?

Basically if 80% of situation when Nodes wired up without template -> they are handled by MVC controllers then it's fine - if it's ONLY 20% then I think changing it so the default suits the most likely scenario is preferrable - but also making sure both is possible - but likely in a more intuitive and creative way, eg doc type setting etc

[cg-hurst]

I also use the TreeNodeRenderingNotification in order to add an icon to Content items and Media Folders that have been protected by our gated disclaimer (a legal requirement for some sites we work on that has to be accepted before the content can be viewed :/ ).

Is it possible to manipulate the text or icons in the Content Tree and Media Tree in some other way?

[markadrake]

I haven't released this for v15+ yet, but I was able to get this working through the use of middleware. So far, it works on the content tree and media tree. (In v13, you could pretty much override any tree icon.)

[cg-hurst]

I might be able to do something with that, but to clarify our current feature, we added a css class via the notification handler and then used that to fashion a small overlay badge (see attached, hopefully).

With shadow DOM and the web component approach this won't work anyway. I've noticed that the indicator that an element is saved but unpublished has also gone so I'm assuming there are no annotations anymore.

Still it would be good if there was some way to either add an icon / badge to the tree menu item somewhere to indicate the status of the node.

[keremkambur]

we just need those c# events back!!
ABSOLUTELY

[markadrake]

@cg-hurst,

I might be able to do something with that, but to clarify our current feature, we added a css class via the notification handler and then used that to fashion a small overlay badge (see attached, hopefully).

With shadow DOM and the web component approach this won't work anyway. I've noticed that the indicator that an element is saved but unpublished has also gone so I'm assuming there are no annotations anymore.

Still it would be good if there was some way to either add an icon / badge to the tree menu item somewhere to indicate the status of the node.

AFAIK there's no API to influence or change how these icons are rendered. My first approach to porting my custom backoffice icons package to Umbraco 15 was to monkey patch the client side rendering method:

import { html, nothing, classMap } from "@umbraco-cms/backoffice/external/lit";

const ICON_STORAGE_KEY = "Humble.Umbraco.CustomBackofficeIcons";

// Wait for the original class to be defined
customElements.whenDefined("umb-document-tree-item").then(() => {

    // Stripping this out, not important
    const getIcons = async () => {
    };

    let iconsMap = {};
    getIcons().then((icons) => {
        icons.forEach(({ key, icon, iconColor }) => {
            iconsMap[key] = { icon, iconColor };
        });
    });

    const originalClass = customElements.get("umb-document-tree-item");

    // Private properties
    function getPrivateField(instance, fieldName) {
        const privateField = Object.getOwnPropertySymbols(instance).find(symbol =>
            symbol.toString().includes(fieldName)
        );
        return instance[privateField];
    }

    originalClass.prototype.renderIconContainer = function() {
        const isDraft = getPrivateField(this, "#isDraft");
        const renderStateIcon = getPrivateField(this, "#renderStateIcon");

        // Look up the custom icon in our icons map
        const key = this.item?.unique;
        const customIconData = key ? iconsMap[key] : null;
        let icon = customIconData ? customIconData.icon : this.item?.documentType.icon;
        icon += customIconData ? ` color-${customIconData.iconColor}` : "";
        const iconWithoutColor = icon?.split(' ')[0];

        return html`
			<span id="icon-container" slot="icon" class=${classMap({ draft: isDraft })}>
				${icon && iconWithoutColor
                    ? html`
                        <umb-icon id="icon" slot="icon" name="${this._isActive ? iconWithoutColor : icon}"></umb-icon>
                        ${renderStateIcon}
                    `
                : nothing}
			</span>
		`;
    };
});

I settled on Middleware, but my needs are different.

[skttl]

Are you hijacking the management api requests for your middleware then?

[markadrake]

@skttl something like this:

    public async Task InvokeAsync(HttpContext context)
    {
        // Only intercept the specific endpoint
        if (context.Request.Path.StartsWithSegments("/umbraco/management/api/v1/tree"))
        {
            var originalBodyStream = context.Response.Body;

            using (var memoryStream = new MemoryStream())
            {
                context.Response.Body = memoryStream;

                await _next(context);

                context.Response.Body = originalBodyStream;
                memoryStream.Seek(0, SeekOrigin.Begin);

                var responseBody = new StreamReader(memoryStream).ReadToEnd();
                var modifiedResponseBody = await ModifyResponse(responseBody);

                await context.Response.WriteAsync(modifiedResponseBody);
            }
        }
        else
        {
            await _next(context);
        }
    }

The ModifyResponse method will swap icons that have been overridden.

Again, I'm not a fan of either method. This is a limitation of either not knowing or not being provided with the appropriate integration point in Umbraco. In v13, I made use of the following:

[nielslyngsoe]

Hi @markadrake If I read your code right, it seems like you are looking to bring your own icons?

Could you let me know if our documented way on how to bring your own icons could work for your case?
https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-types/icons

In regards to adding badges/status to Documents, then this is a future feature we will be looking into in near future, so until then a hack is needed.
More custom icons could be a way, another way could be to bring your own icon provider(Icon registry) via JS. Such could generate icons based on the given name... cause a icon-registry just has to bring an SVG, but nothing hindering that could be a composed SVG... The Registry doesn't need to know all possible icon names, you could just accept everything starting with mark-drake:...
This would clearly be a custom hack, but it is an opportunity.
https://uui.umbraco.com/?path=/docs/symbols-icon-registry--docs