Pushover: support HTML, URL title and custom sounds

[tdabasinskas]

Extending Pushover integration to allow extended customization:

• New sound parameter for a custom notification sound.
• New url_title parameter, which allows setting custom text for the supplementary URL.
• HTML formatting support within the messages.

As for the last one, I've enabled HTML support for all the messages, as I don't really see the reason why not to do so (either way, you need to use explicit HTML tags within your message to use this functionality). Anyhow, if you think otherwise, I'm good with making this configurable as well.

[simonpasquier]

message should be rendered through tmplHTML() rather than tmpl(). Also I suspect that you need to add pushover.default.url_title and pushover.default.sound to template/default.tmpl.

[tdabasinskas]

Hi @simonpasquier ,

Thanks for the comments.

OK, since you mentioned HTML message contents should be handled via tmplHTML, I've decided to add optional (defaulting to true) HTML parameter for this notifier. Now, if the parameter is enabled, we use tmplHTML() to render the message; otherwise - we use tmpl().

Regarding adding the default sound and url_title values to the default template, I considered doing that, but I think it's better to leave these empty by default, which means the user's default sound will be used and the title of the URL will be the same as the URL itself.

Please let me know if any further changes are required.

[simonpasquier]

Regarding adding the default sound and url_title values to the default template, I considered doing that, but I think it's better to leave these empty by default, which means the user's default sound will be used and the title of the URL will be the same as the URL itself.

The problem is that pushover.default.url_title and pushover.default.sound aren't defined in the default template so the notification will fail without additional configuration. I suggest that you leave the default values as ''.

[tdabasinskas]

Hi @simonpasquier ,

I've removed the default values for these two fields and confirmed it's working when they are not set.

Anyhow, it seems that the travics-ci job is failing and I'm not sure why.

[simonpasquier]

It was a transient Travis issue, I've triggered the tests and it's all green now. I'd prefer to have text-only notifications as the default to stick with what existed before. @mxinden @stuartnelson3 might have another opinion though.

[mxinden]

@mxinden @stuartnelson3 might have another opinion though.

No opinion on this from my side.

[tdabasinskas]

Hi, @simonpasquier,

Are we still pending on something to have this merged?

[simonpasquier]

Lets wait whether or not @stuartnelson3 is fine with notifications being sent as HTML by default.

[stuartnelson3]

I have the same opinion as @simonpasquier. Even though we haven't reached a major version release yet, it would be nice to maintain behavior when possible, to prevent surprises for users. Since users have to explicitly write HTML tags in their messages, they can also opt-in to enable HTML at that point.

[tdabasinskas]

@simonpasquier , @stuartnelson3 ,

As requested, I've made the HTML to be disabled by default.

[simonpasquier]

👍