Separated Notifications and Emails: Check ins and Check outs

[Godmartinz]

Description

This separates Check in/out Notifications from Check in/out Emails. This fixes the triggers of Notifications happening twice and places the CC emails in the CC field for emails.
mail is now structured with a Mailable::class and sent with the Mail::class
Check out/in Email markdowns have been moved to views/mail/markdown/

The To address behavior has changed here. the alert emails and cc email are no longer registering on the To address line. they will be handled on the cc address line. In case you need to change your third party mail app.

The from email is what is set for the env variable MAIL_FROM_ADDR, but it defaults to service@snipe.it.io
Below you see the To: field being the checked out to, and the CC: field being the alert emails and CC email:

The markdown is unchanged just relocated in the project:

Fixes #15641

Type of change

Please delete options that are not relevant.

• [X ] Bug fix (non-breaking change which fixes an issue)
• [X ] New feature (non-breaking change which adds functionality)
• Breaking change (fix or feature that would cause existing functionality to not work as expected)
• This change requires a documentation update

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Test A
• Test B

Test Configuration:

• PHP version:
• MySQL version
• Webserver version
• OS version

Checklist:

• I have read the Contributing documentation available here: https://snipe-it.readme.io/docs/contributing-overview
• I have formatted this PR according to the project guidelines: https://snipe-it.readme.io/docs/contributing-overview#pull-request-guidelines
• My code follows the style guidelines of this project
• I have performed a self-review of my own code
• I have commented my code, particularly in hard-to-understand areas
• I have made corresponding changes to the documentation
• My changes generate no new warnings
• I have added tests that prove my fix is effective or that my feature works
• New and existing unit tests pass locally with my changes

[what-the-diff]

PR Summary

• Refactored Email Notifications
  The way email notifications are sent has been made simpler and more direct. We introduce several new classes (CheckinAccessoryMail, CheckinAssetMail, etc.) to handle different kinds of notifications. The logic now chooses the correct class based on the item type, simplifies language settings, and enhances log messages for easier debugging.

• Added Classes for Consumable and License Seat Checkouts
  Two new classes (CheckoutConsumableMail and CheckoutLicenseMail) are introduced. They handle emails related to consumable and license seat checkouts. The AdminRecipient class is also updated for better email management.

• Improved Notification Classes
  The notification classes have been overhauled to use SlackWebhookChannel, leading to better maintainability. Email sending logic in these classes is commented out, possibly signaling a shift in notification strategy or temporary disabling of user-related email notifications. Also, redundant checks related to email sending have been removed – hence, resulting in more streamlined code.

• Updated Notification Sending for Slack
  The process of sending notifications to Slack has been changed by directly using SlackWebhookChannel. This alteration exists in the 'CheckoutLicenseSeatNotification.php' file. Also, clutter-causing checks and conditions related to email notifications have been removed from the same file.

• Introduced New Dependencies
  Two new dependencies, named symfony/http-client and symfony/mailgun-mailer, have been included in the 'composer.json' file.

• Renamed Notification Templates
  Several notification markdown views have been renamed in the 'resources/views/mail/markdown/' directory. A new template named 'checkout-asset.blade.php' for checking out assets in Markdown format has been introduced.

• Code Clean Up
  Several view files have been refactored promoting better indentation and readability, with no changes in functionality. Additional models (Accessory, Asset, LicenseSeat, User) were imported into the routing logic.

[Godmartinz]

Tests need rework..will take a look at that tomorrow.

[snipe]

@Godmartinz I honestly don't remember. I don't think so, but you'd have to look at the existing code.

[Godmartinz]

Yea, I don't see that feature present in the project as of right now. I removed it from the test.

[Godmartinz]

This should be good to go now, The tests that are failing should clear up when tests on develop are good again. 🤞 Taking it out of WIP, will double check in the morning.

[marcusmoore]

I think I had a hand in leading you astray...

We actually don't want to send emails for check in/out to the addresses listed in "Send alerts to" in settings...those are supposed to get "low inventory, license expiration, and warranty expiration" notifications...

So for the emails that this PR is working with we should only be dealing with the cc email...

[snipe]

I think these should be in try/catches when we trigger the alerts though, so we don't create 500s if someone has their email address or slack wrong.

[Godmartinz]

The alerts are wrapped in try catches in the checkoutable listener.

[snipe]

@Godmartinz isn't this actually initiating the send tho?

https://github.com/snipe/snipe-it/pull/15681/files#diff-b463d9fd627c8705fc22d512ea776cdec9cdddf67f476c26acd28ed0c40f0de6R79

GitHub

Separated Notifications and Emails: Check ins and Check outs by Godmartinz · Pull Request #15681 · snipe/snipe-it

Description This separates Check in/out Notifications from Check in/out Emails. This fixes the triggers of Notifications happening twice and places the CC emails in the CC field for emails. mail is...

[Godmartinz]

it is, line 65 is the beginning of the try/catch though. does that not work the way I think it does? 🤔

[snipe]

I mean, it's easy enough to test. Change your email notification and/or webhook URL to something that isn't valid (directly in the DB so you skip validation) and tail the log to see what happens.