Ability to use more than one notification type at a time

[bonelifer]

The ability to use more than one notification type at a time would be nice.

[mag37]

Thank you for the suggestion.

It is currently not possible and not easily implemented I'm afraid without creating a custom template.

I'll look at it, though currently have a few other things that needs attention.

In the meantime - I'd suggest checking out Apprise!
Or I'd you'd tell me which templates you would like to combine I could try to write a custom one here.

[vorezal]

I have a thought on a solution to this, but it would require a rework. Not sure if that would be acceptable or not. I can't think of a way of doing it without changing function names within each template.

I think I would create a new wrapper script for the send_notification and dockcheck_notification functions, then each individual notification channel's function could be called conditionally if it has been sourced. Renaming those functions would be breaking, but considering the current deployment method involves manually renaming the template you want, maybe that's fine? Open to thoughts and happy to attempt a PR.

[mag37]

I've been considering this too and indeed sourcing multiple files with the same function names would cause issues.

A rewrite that would break current setup and force people to update/modify their notifications is something I'd like to avoid, and this might be a quite niche use case.

An idea that just sprung up (not tested and possibly ugly) - maybe it's possible to iterate multiple files and source them one by one to then trigger the notification once per sourced.

This is currently not a priority so I've not invested any time or actual testing.

[vorezal]

I think this could be done without breaking anyone's existing setup. The current method to enable notifications is to copy a template to notify.sh, which is untracked. We would just need to make sure the calls from dockcheck.sh did not change and we don't create or overwrite notify.sh in any way. At worst users would get template update notifications if template file version change, which are not automated and would require manual action. Those could be disabled if anyone didn't want to use the new feature.

The reason I'm pushing for this a bit is because adding a wrapper allowed me to do some interesting things like consolidate a fair amount of templating logic and implement a "snooze" feature to prevent renotification on a per item basis for a customizable period of time. I've almost got it written up in a way that I will be using personally, so I'll likely be submitting a PR for review in case all that is a direction you would like to go or is useful to others.

[mag37]

Sounds promising!

Yes as long as it doesnt break someones current setup - manual intervention to upgrade to new functionality is fine!
I'd like to avoid that a new main release drops and a user upgrades to then have their notification broken. Especially now when it's possible to have unattended self-upgrades.

I'm eager to hear/see your ideas and work!

[vorezal]

Attempted with #182. I may have gone a little overboard on the scope of the refactoring for a single PR, but let me know what you think!

[mag37]

@bonelifer this is now merged to main with a LOT of help by @vorezal