Task notification plugin

[Kathenae]

Task notification plugin

This pull request adds a new plugin to the application that provides email notifications for task completion, failure, and removal. The plugin can be accessed from the "Task Notification" tab on the main menu and allows users to configure the SMTP server settings and enable/disable notifications for different events.

Changes:

• Modified app/models/task.py and app/plugins/signals.py to send a signal whenever a task fails during processing
• Create a new plugin called Task Notification that allows users to configure SMTP server settings and enable/disable notifications for task completion, failure, and removal.
• Created a new ConfigurationForm class in coreplugins/tasknotification/plugin.py that defines the form fields for SMTP server settings and notification options.
• Added a new coreplugins/tasknotification/config.py module that provides methods for loading and saving SMTP server settings from a configuration file.
• Created a new coreplugins/tasknotification/email.py module that defines a send() function for sending email notifications using the SMTP server settings.
• Added the coreplugins/tasknotification/signals.py module to include event handlers for task completion, failure, and removal that use the send() function to send email notifications if the corresponding notification option is enabled in the plugin configuration.

Note: Configuration settings are saved in a .conf file on the plugin directory, and it is .gitignored since the raw password and other potentially sensitive configuration info is being saved.

This is related to this issue #1341 where an email plugin was considered along with improvements to the existing diagnostics plugin (see PR #1344)

[pierotofy]

Hey thanks @Kathenae this looks great! I will need a few days to look over this as I realized that the plugin interface currently lacks a way to communicate whether a plugin is active/inactive, so if I disable the plugin it will continue to intercept the task_* notifications (even though it shouldn't).

Also open to suggestions on how to tackle this.

[Kathenae]

Alright thanks for taking that time! As for the active/inactive state maybe have plugins implement an on_active_state_changed function that is called whenever the active inactive state is changed and have the plugins call whatever setup/cleanup code that needs to called? so thats where the signals could be unregistered for example?

…

On Thu, May 18, 2023 at 10:10 PM Piero Toffanin ***@***.***> wrote: Hey thanks @Kathenae <https://github.com/Kathenae> this looks great! I will need a few days to look over this as I realized that the plugin interface currently lacks a way to communicate whether a plugin is active/inactive, so if I disable the plugin it will continue to intercept the task_* notifications (even though it shouldn't). Also open to suggestions on how to tackle this. — Reply to this email directly, view it on GitHub <#1343 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AU5FUKYVOEUIECJGDB7E6EDXGZ64LANCNFSM6AAAAAAYGXFJ6E> . You are receiving this because you were mentioned.Message ID: ***@***.***>

[pierotofy]

In the spirit of keeping things simple, I've opted to tweak get_current_plugin to take a only_active parameter, which allows plugins to verify whether they are enabled or not. Signal registering/deregistering was also an option, but seemed more complicated (and also tricky to implement correctly).

Thanks for the wonderful plugin @Kathenae 🙏

[Kathenae]

Yeah, this approach is much better, avoids having to register/deregister signals across processes, which I'm not sure would have worked.

Always glad to help! thank you for all the awesome work you doing maintaining this project @pierotofy