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.

[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.

[nielslyngsoe]

A short update,
Default Values are now Property Preset Values, and documentation goes here:
https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-types/property-value-preset
(Its part of 15.3-rc)

Most UI you should be able to hide via the Extension Registry methods:
https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-registry/replace-exclude-or-unregister

Hiding Properties is in development. More info will come, I also leaked a bit of info in a comment further down. :-)

[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]

@AndyButland, any news on this?

[AndyButland]

Yes, some - I worked on this last week and have a PR with a resolution that you are welcome to have a look-over: #18380. It's awaiting review and testing at the moment.

[Luuk1983]

Yes, some - I worked on this last week and have a PR with a resolution that you are welcome to have a look-over: #18380. It's awaiting review and testing at the moment.

Probably due in Umbraco 15.4?

[AndyButland]

Yes - correctly labelled now.

[Luuk1983]

@AndyButland, I can confirm that this now works as I expected (in 15.4 rc1), very nice!

[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. :-)

[nielslyngsoe]

A little update on this matter.

The Workspace Info boxes are now an Extension Type, called workspaceInfoApp.

This means you can hide the Links by Excluding the Extension with the Alias Umb.WorkspaceInfoApp.Document.Links
Or bring your own that overwrites it.

Read more about Excluding or Overwriting extensions here:
https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-registry/replace-exclude-or-unregister

[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.

[rsoeteman]

@nielslyngsoe I was pointed to this comment. Currently converting my Media protect package that adds the same protection icon as you have Any news when adding an overlay icon is possible in the new BackOffice? I prefer not to have a hacky implementation using middleware.

[markadrake]

@nielslyngsoe I lost track of this! Thank you for always returning to help the community with questions. I apologize for not responding sooner.

I aim to migrate an extension from version 13 to 15, enabling editors in the backoffice to replace the default icon within a content or media tree. As we all know, the displayed icon is assigned to / comes from the content type. My clients always ask about swapping icons around, so this extension was made to give everyone that capability.

https://www.nuget.org/packages/Humble.Umbraco.CustomBackofficeIcons

[nielslyngsoe]

@markadrake no worries.

Interesting. in that way, you are making the Icon part of the Document instead of Document Type?

That was never the intention, but I see how that was very much possible as -13 got a composed model for both the Document and the Document Type.
We still serve the Document Type Icon as part of the internal known 'tree' and 'item' model to avoid loading the Document Type for just that. But as everything in this thread we generally like to minimize the UI customizations abilities via data models.

Both the Tree Item Element and the Ref Item Element come via the Extension Registry, so theoretically you could bring your own, and that could get the icon from where you like, not sure how you would go about it in that case. But maybe you have a global registry(front-end, it could be a Global Context) of icon-replacements and that is registered for the Document unique(GUID, ID). Then the new Elements could look up in that registry, to see if it should use a different one?

I hope that makes sense :-)

[markadrake]

It gives me a new avenue to consider! I'll definitely look into the Extension Registry to avoid the current hack of a solution. Thank you Niels.

[nielslyngsoe]

Cool, I will though have to say that it may not be the ideal way to solve this — its one way, but not ideal.

Either you replicate the whole element, or you need to make sure your element follows along in each version.

I'm especially concerned about the tree item element, you can have a look for your self here:
src/Umbraco.Web.UI.Client/src/packages/core/tree/tree-item/tree-item-base/tree-item-element-base.ts

Or we could have enabled you to extend our class and then overwrite just the icon part.

But going that route could also be dangerous as it will start making packages and the CMS code more tightly coupled. — And we know from experience that will bring us to a bad place where it will be harder to have things evolving. It is best if it's clear where things can be manipulated/interacted with so it's easier to know which changes of the CMS can be done without ruining packages.

But I think it is really nice that you explorer this and then we will learn from it together. So please let me know how it goes for you and how you think we should tackle this in the future?

Thanks

[r0sj0n]

If this feature is being removed I would like an alternative to setting default values and hiding propertys depending on parentPage . Seems crazy to just remove this feature when it is so widely used. Is there a alternative

[nielslyngsoe]

Hi @r0sj0n

Thanks for sharing your concern, the two specific features you are requesting are in progress. The first one, Default values, is named Preset values to clarify its effect — Default values could be interpreted differently.

Property Value Presets has already taken shape, it's part of 15.3-RC and you can read more about the feature here:
https://docs.umbraco.com/umbraco-cms/customizing/extending-overview/extension-types/property-value-preset

Hiding properties is in development, this will first take form as a front-end feature enabling hiding of properties.
Making it possible for any code running in the workspace to show/hide fields, secondly, without promising when at the current movement of written, the goal is to additionally implement this as a granular user permission. Enabling you to specify which User Groups can View or Write specific fields. Which covers hiding properties with no permissions enabled.

Could you elaborate a bit on the specifics of hiding properties depending on parentPage, I'm interested in hearing how the parentPage affects which properties to be shown?

Thanks in advance :-)

[r0sj0n]

We have a theme and a style property for a page type, we want to be able to choose a theme and a style on some pages, but if we create pages under them we want the same theme but only the style should be able to change. And we have have this code as well:
private static void SetDefaultValueDropdownDependingOnParentAndType(SendingContentNotification notification, string? typeName, int? parentId,
ContentVariantDisplay variant)
{
if (parentId == null || !parentId.HasValue || parentId.Value == NotificationHandlerConstants.ParentIdNotSet)
{
return;
}

var parentContent = notification.UmbracoContext.Content?.GetById(parentId.Value);

if (parentContent != null && typeName == BlockAreaWithTheme.ModelTypeAlias && parentContent.IsDocumentType(StandardPage.ModelTypeAlias))
{
    SetDefaultValueDropdown(variant, EditorValueConstants.BlockAreaWidthAlternative.PropertyAlias,
        EditorValueConstants.BlockAreaWidthAlternative.TextWidth);
}
else
{
    SetDefaultValueDropdown(variant, EditorValueConstants.BlockAreaWidthAlternative.PropertyAlias,
        EditorValueConstants.BlockAreaWidthAlternative.Fullwidth);
}

}

[callumbwhyte]

Following a conversation with @nielslyngsoe, I wanted to share a use case we have that the current implementation does not support...

In some sites we dynamically adjust the Block List editor config (allowed blocks) based on some settings, e.g. per template or for the current logged in user type.

Currently this is possible via the SendingContentNotification.

Having a way to do this via the new JS APIs would be great...

[teeto]

I have a multisite Umbraco v13 that would like to migrate to v15. We use SendingContentNotification to be able to hide Tabs, Groups or Properties based on some configuration per site. We also change the order of the tabs or properties and rename or hide the labels. We also can change the available blocks in a block list property.

[Luuk1983]

I currently still have one notification that I miss to get my packages on feature parity with the Umbraco 13 packages: MenuRenderingNotification. I used to use that notification to handle custom logic and remove the delete button from the menu (or change the description and icon for an administrator). For now I thought Id's settle on using middleware to achieve this even though it's kind of hacky.

But to my surprise I can't find any Management API call that is done when the menu is loaded. If the menu entirely frontend without requiring a call to the backend/management API?? So I have no clue on what call to let my middleware do it's thing :(