Hi all,
I’m working on an Umbraco 16 backoffice extension and I want to customize the delete experience for a specific content type called (Course).
I’ve looked at the docs for custom modals, confirm dialogs, and route registration.
But is a bit unclear.
What I’d like to do is:
Only when deleting a Course node, show my custom confirmation modal.
Other content types should keep using the normal delete modal.
Hi @wkeylinx
The Delete action is an Entity Action, of which you can ‘overwrite’ and bring your own.
There is a similar example in my Codegarden talk from this year — look for the Create Article Entity Action, which brings a different modal for the Create Action only on a specific node.
But your request made me research a bit, and it turns out that we are missing a Condition for the Entity Content Type Unique. That would be necessary for you to be able to show it for the specific Content Type. — This fact is not preventing you from succeeding today, but you would have to bring this condition yourself. — In the linked examples, there is another Condition that is now implemented in Core, that part of the example should give you the framework for how a Condition is made.
I have created a task on bringing this Condition in Core, but currently, I cannot guarantee when it will take place.
Best, Niels
Hi, thanks for the comment!
I managed to create my own modal and define a custom action.
I also created a custom condition to check the entity type and implemented the necessary logic.
However, to read the content type, I need to call a repository service in TypeScript.
The issue is that the UI doesn’t update or reflect the changes when I approve the condition.
The repository returns a subscription, and it takes a few milliseconds to process the request. During that time, the UI doesn’t seem to refresh or re-evaluate the condition properly.
I can get the ID of the entity, but I don’t receive any information about its type that’s why I need to call a repository function.
At this point, I’m out of ideas on how to solve this problem. 
That seems like an error that it does not react to condition updates, that is one important feature of it.
Another thing that got to my mind is that you should be able to get the Document-Type ID just via the Tree Item Context. But i see as writing this that should be made available more explicitly. — We will also be making a Condition for this case in near future, but that will not help you right now.
So consume UMB_TREE_ITEM_CONTEXT
observe .treeItem of the consumed class.
TypeScript will complain but ignorer or do a as any and get into .documentType.unique of the treeitem object. then you have the unique/id/GUID of your interest.
In that way you can avoid the repository call, and maybe this fixes the other problem. 
