This is a POC idea to hook into when content node is Saved or Saved & Published do a $http Get/Post to perform some action such as auto create media folder. Then once successful show a notification with notificationService. This is a POC way to try and get around the current lack of firing a notification from an eventHandler like V6 style.

umbracoNotification.js

//Get the same base module that Umbraco uses
var app = angular.module("umbraco");

//When the module runs/excutes...
app.run(["$rootScope", "notificationsService", "eventsService", function ($rootScope, notificationsService, eventsService) {
    
    //Let's listen for any time formSubmitting
    eventsService.on("formSubmitting", function (e, args) {
        console.log("e", e);
        console.log("args", args);

        //Sad panda :(
        //This event 'formSubmitting' from formHelper.service.js only fires on the relative scope
        //And not the rootScope so have no easy way to listen in for this
        //Need another smart way?!

        //Psudeo code
            //Check for the type of docType that is being saved
            //If type == "magic"
            //Then do $http post or own service/resource with promise
                //Do some funky event stuff - create an auto media folder
            //If success promise
                //Show notificationwith notificationService.add() using JSON response from API $http

    });

    //Let's listen for any time formSubmitted
    eventsService.on("formSubmitted", function (e, args) {
        console.log("e", e);
        console.log("args", args);
    });

    //Let's listen for any time app.ready this is an event on the rootScope that is emitted
    //So this works just lovely
    eventsService.on("app.ready", function (e, args) {
        console.log("e", e);
        console.log("args", args);

        notificationsService.success("Warren", "says hello");
    });

}]); 

Hi mate,

I very very strongly advise that people don't start doing server side stuff based on the client side. This has fundamental issues and it's not meant to be done this way. What if the network connection dies or some other reason why your request can't be completed. If you are doing server side logic - like creating business logic things based on server events... you need to do these on the server using c# events. Secondly, formSubmitting is happening before the other request is completed, looks like you are trying to perform some action on the server side before the other request might even be completed so you don't even know if that first request was successful or not.

Notifications on from the server need to be taken care of from the server + client properly. We also need to take care of what happens when events are cancelled, etc... and how we store that information in the current request messaging queue to give back to the client. Unfortunately this is where things will start to get real messy because the correct way to do it would mean updating every cancelable method to return a status, alternatively (and even uglier) is to have a request based object that stores this information which can be retrieved later (i.e. ServiceEvents.GetStatus() ), but that is just awful and not user friendly at all.

I'm also pretty sure that nobody has created an issue for this on the tracker BTW.

@Shazwazza Off to create an issue on the tracker for C# events to push out a notification for this now 😄

I understand and agree with your reasonings. I was just trying to think of a temporary way to get around this until C# events pushing notifications is supported.

I came up with this idea after reading the source code for Umbraco and wondering how the UpdateChecker works to show a notification that a new version is available, and this works in a similar way on the backoffice loading it goes off and checks and depending on the result will show that notification message. Hence me thinking of doing this in the same methodolgy.

If anyone reads or follows this thread.
Recommend you vote up the issue here on the Umbraco Core Team Issue Tracker please
http://issues.umbraco.org/issue/U4-5927