Looks like one test failed

@epixa and @spalger - addressed your comments. I added a config to Notifier and put the lifetimes and intervals on it. Let me know your thoughts.

@tylersmalley In this situation, toss the review label on it and assign it back to whichever reviewer feels most appropriate. I'll take it for tomorrow, but it'll need two reviews anyway, so @spalger can take another look when he gets a chance.

This doesn't seem to respect the errorLifetime setting. I changed mine to 5 seconds, but the auto-close still counts down from 300 seconds. I thought it may have been a caching bug, but it doesn't work even after a full page refresh.

@epixa it appears Notifier is bootstrapped before the config is initialized. I was testing by changing defaults, so this got by me.

Is this a logical change to https://github.com/elastic/kibana/pull/6364/files#diff-8441652c6398f70b4afcb491325bc8e9R20?

module.run(function ($rootScope, $interval, config) {
  Notifier.applyConfig({
    setInterval: $interval,
    clearInterval: $interval.cancel
  });

  $rootScope.$on('init:config', function () {
    // provide alternate methods for setting intervals
    // which will properly trigger digest cycles
    Notifier.applyConfig({
      errorLifetime: config.get('notifications:errorLifetime')
    });
  });
});

Also, should we also add warningLifetime and infoLifetime to the advanced configuration?

config.init() is idempotent and returns a promise for when the config is bootstrapped. I'd recommend using that rather than binding to an event on scope.

It'd probably be best to keep the implementation as simple as possible at first. What do you think about changing the config property to notifications:lifetime and applying it to all notification types? If it becomes apparent that individual lifetime values are useful in practice, then we can always expand upon the implementation with type-based lifetimes.

@epixa, I have updated the PR per our conversation. 'change:config' is only called on subsequent updates after the initialization, so we have to use two listeners the but we remove the 'init:config' listener after it has been called.

LGTM

@tylersmalley I'm merging this and handing you another pull to make a small change