Page 1 of 1

Feature Request: Per API KEY preferences

Posted: Thu Jan 05, 2012 10:19 pm
by ChrisKnight
Howdy,

I apologize if this has previously been requested. I would LOVE it if I could set preferences on a per API key basis. Sometimes I want to turn off my Nagios alerts from work, but I don't want to disable audible alerts from my home alarm system. The more I integrate Prowl with the various notification systems in my life, the more I find that a global 'do not disturb' has the potential to mess me up.

Thanks,

-Chris

Re: Feature Request: Per API KEY preferences

Posted: Sun Jan 08, 2012 12:52 am
by zac
This is an interesting question, and sort of why emergencies ignoring quiet hours is a preference.

The complexity of making the preference per API key, and whether or not people would be able to use it, is my biggest concern.

Re: Feature Request: Per API KEY preferences

Posted: Sun Jan 08, 2012 1:19 am
by ChrisKnight
zac wrote:This is an interesting question, and sort of why emergencies ignoring quiet hours is a preference.

The complexity of making the preference per API key, and whether or not people would be able to use it, is my biggest concern.


OK, how about this... Rather than 'per api key', add a new api value for 'schedule number'; where schedule number is 0 thru 9 and defaults to 0 if not specified.

When using the email gateway, this would be specified as API+priority+schedule@api.prowlapp.com

That way the app doesn't have to manage configurations for a dynamic list of APIs, it only needs to manage ten schedule slots. Each schedule slot would just have allow settings for "Ignore Emergencies" and Quiet Hours.

-Chris

Re: Feature Request: Per API KEY preferences

Posted: Sun Jan 22, 2012 9:34 pm
by phirephly
I think the simplest solution would be to simply have the less important alerts be a -1 or -2 priority, and just set their alerts to "none" when you're not interested in them. Maybe locally scheduling alert profiles would solve the issue, but I agree that that would get very complicated for a relatively rare use case.