Support email sending in single-run mode

[chicco785]

Describe the issue

I would like to be able to send email including the generated report within single-run mode. This would be very useful to schedule job generation reports in a k8s and send reports to no IT users.

Would you accept a PR?

Application call

• type of call: single-run

Template file

N/A

Configuration file

This is the proposed configuration addition:

email:
  enabled: true
  smtp_address: smtp.freesmtpservers.com
  smtp_port: 25
  from: outgoing@example.com
  body: Top report is top top here
  subject: Report subject
  enable_starttls_auto: true
  to: 
    - incoming@example.com

smtp user and passwords should be loaded from env variables

Environment (please complete the following information):

N/A

[divinity666]

I get your point. The feature provided for that is the webhook functionality. You can register your callbacks and get notified once a file is ready. From my perspective, it would be better to use this feature and maybe add a function to return the file as binary stream or so.

I am not a big fan of adding a smtp client to the reporter to be hones. Reason is, that this will add further complexity, which might not be needed in this service, e.g. we will most likely need additional templating language, sanitization etc. If we could use the existing webhook functionality and maybe add a call for returning the file, I would be happier.

Does this make sense?

[chicco785]

While I get your perspective, I don't think the webhook path provide a solution to our use case:

• not IT skilled users or in general target customers for our domain (energy), will be able access reports only via email
• having to relay on a webhook to send an email once per week or per month will not be trivial:
  1. base64 encoding of the report and inclusion as part of the payload should be supported
  2. develop an additional service - should be always running conflicting with the idea of "job" scheduling - to get the webhook notification, extract the body, generate the file, include it in an email and send it.
• like the webhook is sending basic knowledge, so should the email.

I am targeting something very basic, ~40 lines of code will do:

            from_email  = config.email_from
            to_emails    = config.email_to
            subject     = config.email_subject
            body        = config.email_body
            file = to_file

            if config.email_enabled == true
              logger.info("Sending email...")
              
              smtp_config = {
                address:              config.email_smtp_address,
                port:                 config.email_smtp_port,
                user_name:            ENV['SMTP_USER'],
                password:             ENV['SMTP_PASSWORD'],
                ssl: config.email_enable_ssl,
                authentication:       config.email_authentication_method,
                enable_starttls_auto: config.email_enable_starttls_auto
              }.reject { |_, v| v.nil? || v == "" }

              logger.info("Configuration: #{smtp_config}")

              Mail.defaults do
                delivery_method :smtp, smtp_config
              end
              
              mail = Mail.new do
                from    from_email
                to      to_emails.join(", ")
                subject subject
                body    body
                add_file to_file
              end
              
              begin
                mail.deliver!
                logger.info("Email with PDF attachment sent!")
              rescue => e
                logger.error("Failed to send email: #{e.message}")
                logger.error("Backtrace:\n#{e.backtrace.join("\n")}")
              end

[divinity666]

I am honestly still not convinced that this approach makes sense to implement and maintain within this tool. I would still vote for adding a small node-red container to your cluster, where you can put the glue code in (i.e. catch the webhook, call /view_report. and send by mail). My point is, that I could easily think that others want an integration to other systems like Teams, Slack or whatever else.

Anyway, I am willing to accept a PR, when you add appropriate tests and integrate your code seamless to the other configurations. I would also vote for allowing smtp user and password to be configured by the configuration file and only add ENV as fallback, to support local installations as well with this feature.

[chicco785]

what about code hook? I am not a ruby coder, but probably like in other programming languages there is an elegant way to defined at configuration time a method to be imported and executed.

do you have guess, i can look into?

[divinity666]

There is no plugin system implemented for such a feature extension.